产品经理的 Agent 入门
Agent 的自主性
理解 Agent 自主权的产品含义，以及什么时候应该使用 Skill、Workflow、人工确认或多个 Agent。
「产品经理的 Agent 入门」之六
上一篇：Agent、Skill、Tool 与 MCP · 系列入口 · 下一篇：Agent 产品的状态管理
许多演示把“系统自己做了很多步”当卖点。但真实产品里，每多一层自主决策，就多一条可能出错、越权、超时或无法解释的路径。
对产品来说，**自主权（Autonomy）**不是一个抽象的智能等级，而是系统可以在没有用户逐步确认时读取哪些信息、作出哪些判断、执行哪些动作。它应该被明确分配，而不是默认打开。
默认从单 Agent 开始
单 Agent + Tools
→ 重复方法抽成 Skill
→ 窄任务拆成 Specialist
→ 关键路径用 Workflow 固定
→ 高风险节点加入 Approval
→ 全链路加入 Trace、Eval 与 Replay只有当真实任务暴露出边界，系统才增加相应结构。
什么时候才需要拆成多个 Agent
一个子任务通常需要反复出现，输入输出清楚，需要独立上下文、模型、工具或权限，能够单独评估，而且失败不会让整个系统失控。
如果只需要固定方法，用 Skill；只需要一个动作，用 Tool；步骤明确，用 Workflow Node。给每个组织角色都做一个 Agent，通常只是把组织架构投射进软件。
常见编排模式
| 模式 | 适合问题 | 关键风险 |
|---|---|---|
| Supervisor + Specialists | 多专业分析，需要统一责任 | 主 Agent 只拼接、不判断 |
| Router + Handoff | 领域清楚的分流 | 交接丢失上下文 |
| Workflow / Graph | 可审计、可恢复的关键流程 | 分支设计过重 |
| Parallel + Aggregator | 技术、商业、风险并行评审 | 重复观点、冲突无人处理 |
| Generator + Reviewer | PRD、代码与合规门禁 | 无限迭代、没有 Rubric |
| Role-based Crew | 早期实验 | 退化成角色扮演群聊 |
对于会议纪要到 PRD，合理结构可能是主 Agent 判断阶段，BRD、产品定义、PRD 与评审作为 Skills，阶段由 Workflow 管理，必要时再由独立 Reviewer 按 Rubric 评审。它不需要五个 Agent 互相开会。
把确定性留给系统
权限判断、数值计算、Schema 校验、状态流转、幂等、版本和冲突检测都更适合确定性系统。模型可以建议把需求改为“可评审”，系统必须根据门禁与权限决定是否允许写入。
本篇小结
- 自主权应按读取、判断和执行动作分别设计，不应把“完全自主”当作默认目标。
- 能用 Tool、Skill 或 Workflow 解决的问题，不需要额外创建 Agent。
- 多 Agent 只有在子任务需要独立上下文、工具、权限或评估时才值得引入；角色更多不等于产品更先进。
能用 Tool 解决的，不新建 Agent；能用 Skill 约束的，不增加自由对话；能用 Workflow 固定的，不依赖模型临场发挥。