AI PM Playbook

Appearance

Aurora/AgentOS 案例：Agent 操作系统的产品设计 ​

2026-05 更新版：本文将 Aurora/AgentOS 从“多 Agent 编排框架”的旧叙述，更新为面向生产环境的 Agent Runtime & Governance Platform 案例。重点关注 MCP / A2A 生态、工具权限、沙箱执行、trace 回放、Agent 预算、持续评估和企业治理。

一、背景 ​

1.1 行业背景 ​

2024-2025 年，AI Agent 从概念验证走向产品落地。到 2026 年，Agent 产品的难点已经不再是“能不能让模型调用工具”，而是：

  • 工具连接标准化后，如何防止工具滥用和越权；
  • Agent 自动执行时，如何设置预算、审批、回滚和审计；
  • 多 Agent 协作时，如何避免错误级联、状态混乱和成本失控；
  • 企业客户如何获得可回放 trace、策略控制、权限边界和数据隔离；
  • MCP、A2A、AGENTS.md 等开放约定普及后，平台如何建立差异化。

早期 Agent 框架强调 prompt、chain、workflow 和 tool calling。生产环境则更需要一个 Agent 操作系统：为 Agent 提供运行时、工具治理、状态管理、可观测性、安全策略和持续评估。

1.2 项目起源 ​

Aurora 项目最初服务于一家企业级 AI 公司。团队在构建客服、数据分析、销售运营、代码审查等 Agent 时发现，单场景 Demo 很容易，但生产化很难：

  1. Agent 数量从 3-5 个扩展到 50+ 后，依赖和状态迅速复杂化；
  2. 一个 Agent 的错误会通过工具调用和消息传递放大到整个工作流；
  3. 不同 Agent 对同一工具的权限要求不同，简单 API key 模式不可控；
  4. 企业客户要求完整回放“为什么执行了这个动作”；
  5. 成本不再按单次聊天计算，而是按 run、step、工具调用和重试累积。

因此，Aurora 从内部编排引擎升级为 AgentOS：生产级 Agent 运行时与治理平台。

二、产品定位 ​

2.1 核心价值主张 ​

Run agents safely, observably, and economically in production.

AgentOS 的定位不是另一个 Agent Demo 框架，而是 Agent 的生产运行层，类似 Kubernetes 之于容器、API Gateway 之于微服务。

核心能力：

  1. Agent Runtime：管理 Agent run、step、状态、重试、超时和回滚；
  2. Tool Governance：工具注册、权限、参数约束、审批、速率限制；
  3. Context & Memory：短期状态、长期记忆、组织上下文、权限过滤；
  4. Observability：trace、日志、指标、可视化调试、回放；
  5. Policy & Approval：风险分级、人工审批、策略网关；
  6. Continuous Evals：线上失败样例回流、回归测试、版本对比。

2.2 与现有框架的关系 ​

text
应用层：客服 Agent / 数据分析 Agent / Coding Agent / 内部运营 Agent
        ↓
Agent 框架：LangGraph / LlamaIndex / CrewAI / 自研 workflow
        ↓
AgentOS：运行时 | 工具治理 | 权限 | 沙箱 | 记忆 | 评估 | 审计
        ↓
基础设施：LLM / MCP Servers / APIs / DB / Queue / Sandbox / Storage

AgentOS 不替代上层框架，而是为它们补齐生产级能力。

2.3 目标客户 ​

客户类型核心痛点AgentOS 价值
企业 AI 平台团队Agent 分散、权限不可控统一运行时和治理
SaaS 产品团队要把 Agent 嵌入现有产品工具权限、审计和成本控制
Coding Agent 团队代码执行、PR、文件写入风险高沙箱、审批、trace、回滚
数据分析团队Agent 可能访问敏感数据权限过滤、SQL 审批、审计
大型企业 AI CoE需要统一标准和治理策略模板、评估体系、合规报表

三、核心设计 ​

3.1 系统架构 ​

text
┌──────────────────────────────────────────────────────────┐
│                    Agent 应用层                           │
│  Support Agent | Data Agent | Coding Agent | Ops Agent    │
├──────────────────────────────────────────────────────────┤
│                    Runtime Control Plane                  │
│  Run Manager | Step Scheduler | Retry | Timeout | Rollback│
├──────────────────────────────────────────────────────────┤
│                    Tool & Context Plane                   │
│  Tool Registry | MCP Connector | Permission | Memory      │
├──────────────────────────────────────────────────────────┤
│                    Safety & Policy Plane                  │
│  RBAC/ABAC | Approval | Risk Scoring | Budget | Sandbox   │
├──────────────────────────────────────────────────────────┤
│                    Observability Plane                    │
│  Trace | Logs | Metrics | Replay | Debugger | Eval Store  │
├──────────────────────────────────────────────────────────┤
│                    Infrastructure Layer                   │
│  LLM Providers | APIs | DB | Queue | Vector DB | Storage  │
└──────────────────────────────────────────────────────────┘

3.2 Agent run 生命周期 ​

text
创建 run → 载入上下文 → 计划 step → 选择工具 → 策略校验
      → 执行动作 → 观察结果 → 记录 trace → 评估是否继续
      → 完成 / 等待审批 / 失败 / 回滚

每个 run 都有：

  • run_id；
  • 用户和组织身份；
  • 风险等级；
  • 最大 step 数；
  • 最大成本预算；
  • 工具白名单；
  • 审批规则；
  • 完整 trace。

3.3 工具治理 ​

工具是 Agent 最大的风险面。AgentOS 采用“工具注册 + 权限 + 参数约束 + 审批”的组合。

治理项说明
工具注册每个工具必须有 owner、schema、风险等级、审计策略
最小权限Agent 只能调用被授权工具
参数校验使用 JSON Schema / 类型约束 / 业务规则
动作分级只读、低风险写入、高风险写入、外部发送
人工审批高风险动作必须确认
沙箱执行代码、文件和浏览器操作隔离运行
速率限制防止循环调用和成本失控
审计记录输入、参数、结果、审批人全部记录

3.4 MCP / A2A 生态下的产品策略 ​

连接协议标准化会降低工具接入成本，但不会自动解决生产治理。

标准化带来的变化AgentOS 应对
工具接入更容易提供 MCP server registry 和安全扫描
Agent 间通信更通用提供 A2A 消息审计和边界控制
项目说明更标准支持 AGENTS.md / policy file 版本管理
schema 更清晰自动生成测试和权限规则
供应链风险上升工具来源验证、签名、隔离和风险评分

关键判断：协议解决连接问题，AgentOS 解决可信执行问题。

四、产品关键决策 ​

决策 1：Run 级预算优先于全局预算 ​

Agent 成本具有尾部风险。全局预算只能防止月度超支，run 级预算才能阻止单个任务无限循环。

yaml
run_budget:
  max_steps: 12
  max_tool_calls: 20
  max_duration_seconds: 300
  max_credits: 50
  on_exceed: require_human_approval

决策 2：高风险动作默认人工审批 ​

AgentOS 将动作分为四类：

等级示例策略
L1 只读搜索、读取文档自动执行
L2 低风险写入创建草稿、生成报告自动或轻提示
L3 高风险写入发邮件、改配置、提交 PR人工确认
L4 不可逆动作支付、删除数据、生产发布多人审批 / 默认禁止

决策 3：Trace 是核心产品，不是调试附属品 ​

企业客户需要回答：

  • Agent 看到了哪些上下文；
  • 调用了哪些工具；
  • 为什么选择这个动作；
  • 谁批准了高风险步骤；
  • 是否访问了敏感数据；
  • 失败时如何回滚。

因此，trace 必须作为一等产品能力，而不是工程日志。

决策 4：失败样例自动进入评估闭环 ​

线上失败不能只作为客服 ticket 处理。AgentOS 自动把失败 run 转成评估样例：

text
失败 run → 分类失败原因 → 生成 eval case → 加入回归集 → 下次版本发布前重跑

五、指标体系 ​

指标类别指标
任务结果run 成功率、任务完成率、人工接管率
执行效率平均 step、平均运行时长、重试次数
工具质量工具选择正确率、工具执行成功率、参数错误率
成本单 run 成本、P95 run 成本、预算触发率
安全越权拦截率、高风险动作审批率、敏感数据访问率
可观测性trace 完整率、回放成功率、失败归因覆盖率
业务客户续费、Agent 采用率、自动化节省工时

六、踩坑与教训 ​

6.1 多 Agent 不一定更好 ​

多 Agent 会增加通信成本、协调成本和错误传播风险。只有当任务可并行、角色边界清楚、验证机制明确时，多 Agent 才值得。

6.2 工具 schema 是产品设计的一部分 ​

工具描述、参数名、返回值结构会直接影响 Agent 表现。不要把 schema 当成纯工程细节。

6.3 记忆必须有权限和过期策略 ​

长期记忆如果不绑定用户、组织、来源、时间和权限，会带来隐私和越权风险。

6.4 审批不能只是弹窗 ​

高风险审批必须包含：动作摘要、影响范围、可回滚性、执行人、审批人、审计记录。

七、PM 可复用清单 ​

  • [ ] 每个 Agent run 是否有预算和 step 上限；
  • [ ] 每个工具是否有 owner、schema、风险等级；
  • [ ] 高风险动作是否需要人工审批；
  • [ ] 是否支持 MCP 工具来源验证；
  • [ ] 是否记录完整 trace；
  • [ ] 是否支持 run 回放；
  • [ ] 是否支持失败样例进入 eval；
  • [ ] 是否支持组织级权限和数据隔离；
  • [ ] 是否支持成本按 run / 用户 / 组织拆分；
  • [ ] 是否有 Agent 版本回滚机制。

八、结论 ​

Aurora/AgentOS 的案例说明：Agent 产品的壁垒不在“能不能调用工具”，而在 能不能安全、可观测、可预算、可审计地持续运行。

随着 MCP、A2A、AGENTS.md 等生态标准化，通用连接能力会越来越商品化。真正能形成护城河的是：企业上下文、权限与策略、可信执行、trace 数据、持续评估和业务工作流嵌入。

MIT License

Copyright © 2026 prodthinkpm