技术/09.01 · 08:17/13 MIN/0 阅读
Product OS：AI产品团队的闭环实践
Product OS 是一个基于 Gemini 和 ADK 2 构建的 AI 产品操作系统，通过多智能体协作，完整走通信号感知、调查、诊断、决策、发布、验证、学习的产品闭环。文章深入解析了架构设计、安全边界和工程实践，并提出了 idea-to-impact time 这一核心指标。
我们不想再做另一个聊天机器人。
一开始就一个问题：真正的 AI 产品团队应该长什么样？
今天大部分 AI 应用擅长回答问题。问模型一个 bug，它能解释；让它分析反馈，它能总结；让它写代码，它能写。
但真实的产品团队远不止这些。它会盯着产品，发现变化，调查原因，和客户沟通，看数据、日志、发布记录和代码，判断是 bug 还是机会，写代码、测试、找对的人审批，发布，再验证是否有效，最后记住这次经历。
这就是 Product OS 的由来。我们想构建一个更像“自主产品团队”而非聊天机器人的系统。
核心循环很简单：
观察 → 调查 → 诊断 → 决策 → 行动 → 审批 → 发布 → 验证 → 学习
重点不是某个单独步骤，而是整个系统能完整走完这个闭环。
三个相互连接的闭环
设计时受了吴恩达（Andrew Ng）观点的影响：把 AI 系统当循环，而不是一个试图解决所有问题的巨型模型。
我们把它应用到产品开发上。
产品循环
产品不断产生信号：转化率下降、崩溃增加、用户反复提同一个需求、某个流程总是卡住。Product OS 盯住这些信号，试图理解含义。
工程循环
问题清楚了，系统进入工程环节：查代码仓库，找到相关代码，提出修复，生成测试，准备 PR。
学习循环
我们最看重的循环。变更发布后，系统检查结果：转化率改善了吗？错误减少了吗？用户不再反馈了吗？实验有效吗？结果沉淀为下一轮的知识。
所以，我们构建的不是 prompt → answer，而是：
信号 → 推理 → 行动 → 测量 → 学习
Product OS 实际做什么
Product OS 是一个控制平面，服务于产品可靠性和增长。
黑客松中我们做了一个独立演示产品 Cove。Cove 是被观察对象，Product OS 是围绕它的操作系统。刻意分开，是因为 Product OS 不该是假装成操作系统的演示店面。
租户可以换，产品信号可以换，调查方式可以换，底层操作系统不变。这种架构更接近实际可复用的产物。
一个信号就能触发完整调查
假设：Safari 结账转化率突然下降。
仪表盘能告诉你转化率降了，但很多系统到此为止。还得有人去查为什么。
Product OS 里，Signal Agent 检测到异常，启动调查。不同 Agent 并行查不同来源：
| Agent | 查看内容 |
|---|---|
| Analytics Agent | 漏斗、转化、行为 |
| Logs Agent | 错误、超时、失败 |
| Deployment Agent | 近期发布和变更 |
| Customer Voice Agent | 受影响用户的体验 |
| Code Agent | 相关代码和实现 |
| Root Cause Agent | 综合所有来源的证据 |
用 ADK 2 工作流而非一个巨型 prompt，原因就在这里。调查可以并行，结果回到一个明确的决策点。ADK 2 提供了这种编排结构。
让客户对话成为证据
这是最有意思的部分。我们不想让 Customer Voice Agent 只是问：
“您为什么没完成支付？”
这样只会得到一个问卷答案。
相反，Agent 能拿到事件上下文：
- 客户尝试支付 ₹4,200
- 设备是 iPhone
- 浏览器是 Safari
- 失败是 3DS 超时
- 客户已尝试两次
- 怀疑 Safari 回归
然后 Agent 问更有用的问题：
“您看到了错误提示，还是支付页面一直加载？”
客户：“一直加载。”
Agent：“换其他浏览器试过吗？”
这时对话产生的是诊断证据。证据结构化后，可以和数据分析、日志、发布数据合并。这比存一份对话记录有用得多。
问题与机会，系统都接
Product OS 围绕两类信号设计。
出问题了：转化率下降、支付失败、崩溃激增、API 错误上涨、留存恶化、发布回归。问题是：发生了什么，怎么修？
可以更好：反复被提的需求、用户卡在同一流程、总去同一个页面、手动绕过产品限制。问题是：能改进什么？
这个区分很重要。Product OS 不只是事故响应系统，也是产品智能系统。
从客户反馈到产品决策
想象 37 个客户分别要求支持 Apple Pay。我们不想要 37 个零散工单，而是让系统识别模式。
Product Agent 能把它变成：
- 功能：支持 Apple Pay
- 频率：37 个客户请求
- 收入影响：估算
- 流失风险：高
- 对手能力：有
- 实现成本：中等
这就是产品提案。下一步可以是实验。
假设：结账时更早展示配送信息会提升转化率。
系统可以推动这个假设走完产品设计、开发、测试、灰度发布和度量。这比“我们觉得这功能有用”好得多。
idea-to-impact time（想法到影响的时间）
这是项目中最有用的概念之一。
传统流程可能是：
客户投诉 → PM 察觉 → 提工单 → 排期 → 开发 → PR → 评审 → 测试 → 发布 → 分析 → PM 看结果
过程没错，问题在于每个环节之间的时间和上下文损耗。
Product OS 试图压缩这个循环：
信号 → 调查 → 客户验证 → 决策 → 实现 → 测试 → 发布 → 度量 → 学习
我们称之为 idea-to-impact time。目标不是把人移出循环，而是缩短从发现重要信号到学会怎么处理的时间。这比单纯说“我们的 Agent 是自主的”更有意义。
为什么用 ADK 2 Workflow
架构里天然有并行：分析、日志、发布、客户调研、代码可以同时查。最终结果要合并。
概念上工作流是这样的：
产品信号 → Signal Agent → Analytics / Logs / Deployment 并行 → 汇总证据 → Root Cause → 分支 bug/opportunity → Code/Product → Tests/Experiment → 审批 → 发布 → 验证 → 记忆
ADK 2 在这里很关键。我们必须把 Agent 看作工作流里的组件，而不是孤立的聊天机器人。
我们也发现，ADK 1.x 的 ParallelAgent、LoopAgent 模式不能直接映射到新的 Workflow 模型。最终我们用了 Workflow、JoinNode、类型化输入和明确的边界，把确定性编排和模型驱动的工作分开。
没有构建一个巨型 Agent
另一个设计选择是不做拥有所有权限的超级 Agent。不同 Agent 有不同职责：有的分析，有的和客户说话，有的写代码，有的做产品决策，有的度量结果，有的判断某个操作是否安全到可以自动执行。
这让系统更容易推理，也形成自然的安全边界。Analytics Agent 不需要 GitHub 写权限，Customer Agent 不需要生产部署权限，Product Agent 不需要客户数据库权限，Code Agent 不应自动发邮件。架构反映这些边界。
A2A 让系统可扩展
我们也围绕 agent-to-agent（A2A）通信设计。Incident Commander 不需要拥有所有能力，它可以协调专业 Agent。
例如：
Incident Commander → Analytics Agent / Customer Agent / Code Agent → Root Cause
这些 Agent 将来可能是通过 A2A 暴露的远程 Agent。这意味着 Product OS 可以成长为一个 Agent 生态系统的协调者，而不是一个巨型应用。核心思想：专业 Agent 应该能协作，不需要把所有能力硬编码进同一套系统。
MCP 把 Agent 接到真实工作上
Agent 能操作实际系统，价值才大。对 Product OS 来说，包括 GitHub、BigQuery、Gmail、Calendar、Drive、Docs、Firebase、分析平台、客户系统、部署系统。
我们用 MCP 和 API 连接 Agent 和这些工具。工具越强大，权限越重要，所以安全架构从第一天就考虑，而不是事后补。
自主但不能无限访问
我们不希望安全模型是“prompt 让 Agent 小心点”。这不是强安全边界。
架构把“Agent 想做什么”和“实际允许做什么”分开：
Agent → Agent Identity → Policy → Agent Gateway → Model Armor / Data Protection → Tool
不同风险级别：
- 低风险：文档修复、测试修复、小型 UI 改动，可以自动。
- 中风险：业务逻辑、支付流程、数据库变更，需要开发审批。
- 高风险：身份认证、支付授权、财务计算、破坏性数据库操作，必须人工审批。
关键不是让一切自动驾驶，而是让自主可控。更好的安全问题是“什么阻止了工程 Agent 访问客户数据？”，答案是“它没有访问的身份和权限”，而不是“prompt 告诉它不要”。
系统还用了 Model Armor 和数据保护，因为它会接触客户信息、支付事件、语音转录、邮件、GitHub 和分析数据。
工具输出也是攻击面
构建中我们发现，只保护模型 prompt 不够。Agent 不断消费外部信息：GitHub issue、邮件、客户消息、文档、外部工具。这些输入可能含恶意指令或 prompt 注入。
所以我们在设计中加入工具输出筛查。这后来成了 Product OS 对 Google ADK 生态的实际贡献之一。
BigQuery 是事实，Memory 是知识
我们不想把所有分析事件倒进 Agent 记忆。BigQuery 管事实，如“支付转化率 81.7%”；Memory 管知识，如“版本 4.3 导致支付回归，被 PR #184 修复”。
Product OS 维护几种记忆：
- 客户记忆：偏好、反馈、历史事故
- 产品记忆：功能请求、已知问题、产品决策
- 工程记忆：bug、修复、回归、部署事故
- 组织记忆：组织通常如何解决某类事故
这创造了一种不同的系统：不只是检索信息，而是积累经验。六个月前的教训可以用于下一次调查。
人怎么看系统
Agent 系统很容易变得难以理解：十个 Agent 在跑，多个工具被调用，几个调查并行，还有一堆隐形状态。
我们要让它可见。Product OS 有：可视化园区、房间、Agent 工作区、可见的交接、审批、记忆、每个 Agent 的视图、聊天。
园区不是架构本身，而是理解架构的界面。人类可以打开一个房间，看到 Agent 在做什么，检查证据，审核审批，理解发生了什么。
我们还刻意避开暗色的“作战室”设计，希望 Product OS 更像 Apple、Stripe 和现代云软件的简洁感。
系统要诚实
这看似小事，却成为重要工程原则。Agent 系统不能谎报“已完成”。连接器明确返回状态：
applied（已应用）、skipped（已跳过）、denied（已拒绝）、reused（已复用）
这在与真实系统交互时很重要。GitHub 方面，Product OS 可以准备并打开 PR，但不自动合并和部署生产。人类留在审批链里，这保持了 Agent 能力与生产权限的边界。
构建过程也有一堆“无聊”问题
很多 Agent 演示停在架构图，看着很美。我们不想这样。
我们处理了常规软件工程问题：Next.js 静态导出行为、动态路由、WebSockets、CORS、OAuth 跳转、Cloud Run 部署、Python 包兼容、移动端布局、图片大小、持久状态、部署失败、环境变量。
例如，本地的 NEXT_PUBLIC_API_URL 可能被意外打进生产 JavaScript 包里。还得区分静态托管和本地开发，让 WebSockets 走正确的同源路径。Cloud Run 也有打包问题，本地 Python 环境和运行时版本不同，原生 wheel 不一致。
就连可视化园区也有工程问题。地图标签在桌面正常，某些手机布局错位，因为图片被包含在不同宽高比里。我们不得不算出实际图片内容框，而不是按整个图片框盲目定位。
这些问题不算“AI 问题”，但它们真实存在，因为我们要做的是实际产品。
回馈上游
我们最自豪的部分之一在 Product OS 仓库之外。
构建中我们发现 Google ADK 有文档缺口和集成问题，于是 fork 了：
提交了 issue 和 PR。部分例子：
- Model Armor 集成文档：PR #2184
- ADK CLI 迁移文档：PR #6962
- 安全插件文档更新：PR #2581
- Model Armor 工具输出示例：Issue #6964、PR #6965
- 首方工具输出筛查：Issue #6966
- ADK 2 迁移指南：Issue #2185、PR #2186
node_as_tool文档：PR #6963
贡献记录是三个 Google ADK 仓库、七个上游项目。
项目本身成了反馈闭环：我们通过做真实项目学 ADK，构建中发现的问题又回馈给生态。
学到了什么
最大的教训：Agent 工程主要不是写巧妙的 prompt，而是：
编排、状态、权限、工具访问、证据、人工审批、验证、记忆
聪明模型只是系统的一部分。系统得知道下一步该做什么。
我们也学到，结构化证据比原始对话有价值得多。一份 transcript 不够。模型说“我觉得这是 Safari 问题”也不够。有用的输出接近：
Safari 用户失败率更高，问题在 SDK 部署后出现，日志显示 3DS 超时，客户反馈一致，受影响人群集中在 iOS Safari。
这才是另一个 Agent 能推理的东西，人类能审阅，也能当知识存下来。
我们真正在意的指标
一开始我们想的是自主 Agent。到后来，想的是学习速度。
问题不是“Agent 多聪明”，而是：
“我们多快能从一个真实世界的信号变成经过验证的改进？”
这就是 idea-to-impact time 的意义。一个产品组织，能更快发现问题、测试假设、发布变更、度量结果，就能更快学习。而更快的学习会复利。
Product OS 下一步
有几个方向想推进：接入分析平台和应用事件的持续产品信号；让实验系统成为一等公民；通过 A2A 让 Agent 更易发现；让组织记忆随时间更有用；强化验证闭环。
最终我们想构建的系统是这样的：
观察 → 理解 → 询问 → 诊断 → 决策 → 构建 → 审批 → 发布 → 度量 → 学习
然后重新开始。
最后
动手建 Product OS 时，我们以为在做多 Agent 应用。到结束时，意识到真正在做的是学习系统。
Agent 重要，工作流重要，工具重要，安全模型重要，界面重要。但最重要的是把它们连起来的那个循环。
观察产品，理解发生了什么，采取行动，度量结果，从中学习。
这就是 Product OS 想成为的东西——不是又一个聊天机器人，不是又一个仪表盘，而是一个连接产品、客户、工程、决策和学习的持续循环的操作系统。
本文是为参加 All Things Agentic Hackathon 而创作。
#AllThingsAgenticHackathon #GoogleADK #ADK2 #Gemini #GoogleCloud #BigQuery #MultiAgent #ProductEngineering #CloudRun #ModelArmor #A2A #MCP
想了解 AI 如何助力您的企业？
免费获取企业 AI 成熟度诊断报告，发现转型机会
