结语　组织如何采用Agent¶

Release Candidate 1

本章回答的三个问题¶

如何选择第一个Agent场景？
团队需要哪些角色、制度和共享能力？
如何在一年内从实验走向可持续采用？

5分钟速读¶

第一个场景应结果可验证、影响可控、反馈频繁且业务价值明确。
不先建设通用Agent平台；先完成一个端到端最小切片。
评估集、Harness和轨迹是共享资产，Prompt不是唯一核心资产。
产品、工程、安全、数据和业务Owner共同负责，不把风险交给AI团队独自承担。
从Shadow和Canary开始，保留人工接管和回滚。
模型和框架会变化，稳定契约、评估和治理能力更重要。

一、选择试点¶

优先：

成功可由测试或业务状态验证；
失败可撤销或人工接管；
当前流程存在明显人工搜索和协调成本；
有足够真实案例建立评估集；
工具权限可以从只读开始。

避免：

一开始就自动执行不可逆高风险动作；
没有数据Owner和成功定义；
仅为展示多Agent或最新模型；
需要一次覆盖全部业务。

二、最小垂直切片¶

第一版只实现：

一个明确Actor和目标；
一条代表性成功路径；
一个失败和恢复路径；
类型化输入输出；
硬预算和终止；
Trace和最终验证；
人工接管。

在真实评估证明需要前，不抽象通用平台。

三、组织职责¶

角色	责任
Business Owner	成功、影响、人工流程和残余风险
Product	用户体验、审批和异常路径
Agent/ML Engineer	模型、Prompt、评估和路由
Software Engineer	Harness、状态、工具和可靠性
Security/Privacy	身份、权限、数据和威胁模型
Domain Expert	政策、Rubric和失败裁决
Operations	SLO、告警、接管和事故响应

四、共享能力¶

经过多个用例验证后再共享：

身份与策略网关；
Tool Registry和沙箱；
状态与Checkpoint；
Trace和Artifact Store；
评估运行器；
Prompt/Schema/Tool版本；
发布与回滚。

共享控制面，不强迫所有业务采用同一Agent拓扑。

五、路线图¶

0–90天¶

选择试点；
建立真实评估集；
采用最低充分自主性；
完成最小切片；
记录结果、轨迹、成本和风险。

90–180天¶

补持久状态、幂等、预算、审批和取消；
建立离线/在线评估；
Shadow与Canary；
生产失败回流评估集；
明确SLO和事故流程。

180–365天¶

抽取已验证共享Harness；
模型路由和成本治理；
从轨迹更新知识、Skill和程序；
对高价值瓶颈评估后训练；
只有通过准入测试再采用多Agent。

六、治理节奏¶

每次版本评审：

质量、延迟、成本和安全变化；
新权限和副作用；
数据和Memory变更；
模型、Prompt、工具和政策版本；
回滚与人工接管；
残余风险Owner。

每季度清理：过时规则、重复Skill、失效评估、未使用工具、长期Memory和权限。

七、采购与自建¶

评估供应商：

模型与工具契约可移植性；
数据使用与保留；
身份和网络集成；
Trace导出；
模型/Prompt版本控制；
SLO、区域和灾备；
成本和退出机制。

托管服务可以降低运维，但不转移业务对授权、数据和结果正确性的责任。

八、最终检查清单¶

[ ] 场景有可执行成功定义。
[ ] 选择最低充分自主性。
[ ] 建立真实私有评估集。
[ ] 权限、预算、审批和回滚完整。
[ ] 生产Owner和人工接管明确。
[ ] 共享能力来自多个验证用例。
[ ] 每成功任务成本和残余风险可接受。
[ ] 模型或供应商可替换。

知识检查¶

第一个试点为什么应从可验证、可控任务开始？
为什么不应先建设通用Agent平台？
哪些资产比单个Prompt更持久？
托管服务不能替组织承担哪些责任？

来源与证据¶

本结语综合全书的架构、评估、安全和发布原则。路线图是组织采用建议，需结合行业监管、数据边界和业务影响调整。

结语 组织如何采用Agent¶