企业试点路线
English | 中文
用阶段退出条件推进试点，不用“先做一个万能 Agent”
每一阶段只增加一种风险：先证明任务和证据，再开放只读工具，然后增加受控写入、恢复和多团队组装。
一个任务单元、一个负责人、一套完成定义。
能力随阶段增加，高风险动作不跨级开放。
每阶段用可观察证据决定继续、修正或停止。
阶段路线图
路线不规定固定周数。不同企业的系统接入、数据分类和安全评审周期差异很大；更可靠的推进方式是为每一阶段定义进入条件、允许能力和退出证据。
| 阶段 | 允许能力 | 必须产出的证据 | 退出条件 |
|---|---|---|---|
| 0 定义任务 | 不接生产系统 | 任务样本、人工基线、完成定义、风险分类 | 团队能一致判断一次运行是否完成 |
| 1 只观察 | 固定材料与模型，不执行工具写入 | 会话记录、错误类型、人工评分分歧 | 输出格式稳定，主要失败能被分类 |
| 2 只读工具 | 搜索、读取、查询和受控计算 | 工具轨迹、引用或查询证据、接管记录 | 结论可回到来源，错误不改变业务状态 |
| 3 受控写入 | 可撤销或低风险写入，逐动作审批 | 审批对、业务幂等结果、补偿和异常记录 | 未批准动作不执行，重复调用不造成重复效果 |
| 4 恢复与扩展 | 持久会话、continuable subagent、第二套 preset | 恢复演练、能力隔离、成本和容量观测 | 崩溃与切换行为符合预期，第二场景无需复制内核 |
Phase 0：把任务说成可验收的单元
先收集真实历史样本，记录人工完成过程、输入材料、允许动作和最终产物。把“提高效率”改写成可观察问题，例如“能否在给定材料中找齐三类字段并逐项给出来源”，而不是先设定收益百分比。
这一阶段还要写出停止条件：输入经常缺失、业务规则没有所有者、结果无法复核，或一次任务包含不可拆分的高风险动作时，项目应回到流程治理，不应把不确定性全部交给模型。
Phase 1：只观察模型与会话
用固定 Agent 组装处理样本，但不开放会改变业务状态的工具。观察会话是否完整记录输入、模型输出、错误和后续修正；建立失败分类，而不是只统计“回答满意度”。
建议至少区分：材料缺失、任务歧义、模型推理错误、工具需求未满足、领域规则冲突和输出格式错误。分类目的是找到该改流程、提示词、工具还是模型，而不是把所有问题归为“模型不稳定”。
Phase 2：接入只读工具
把最稳定的来源封装成只读工具，例如仓库搜索、文档读取、工单查询或数据快照。每个工具需要明确 schema、超时、错误和呈现意图；工具结果应能被业务审核者定位，而不只是塞进一段模型总结。
只读阶段验证的是“回答是否有依据”和“失败是否可接管”。如果 Agent 不能稳定引用来源、区分无结果和系统错误，继续增加写入只会放大不确定性。
Phase 3：加入可撤销的受控写入
优先选择草稿、建议、临时标记或其他可撤销动作。为每个写工具配置策略与审批，业务接口使用调用方身份、幂等键和明确的事务结果。审批文案必须说明对象与影响，不能只问“是否允许调用工具”。
演练拒绝、审批方不可用、工具超时、业务接口部分失败和重复请求。退出证据来自真实状态与日志对照：未批准动作没有副作用，成功动作只有一次业务效果，失败能给人工一个明确恢复入口。
Phase 4：验证恢复、委派和多团队组装
在主路径稳定后，再验证会话恢复、continuable subagent 和第二套 Agent preset。恢复演练应覆盖进程终止、持久化读取和后续消息；委派任务必须能在固定权限下完成，超出权限时返回父 Agent，不在子会话内升级。
第二套 preset 应服务不同任务并拥有不同工具集。如果新增场景仍要复制 Agent loop、会话或 Host，说明能力 seam 或插件边界没有真正发挥作用。
试点计分卡
计分卡定义指标和证据来源，不在蓝皮书中编造目标值。项目负责人应根据人工基线、风险等级和样本分布设置阈值。
| 维度 | 建议指标 | 证据来源 |
|---|---|---|
| 任务质量 | 按验收单完成的样本比例、需要人工重做的原因 | 业务验收表与最终产物 |
| 可追溯性 | 能回到来源或工具结果的关键结论比例 | 会话事件、引用和工具卡片 |
| 控制有效性 | 拒绝、审批、重复调用和异常分支是否符合预期 | 审批事件与业务系统状态 |
| 可恢复性 | 指定故障后能恢复上下文或明确报告不可恢复的比例 | 持久化演练和恢复记录 |
| 人工负担 | 审批、接管、复核和纠错分别花在哪里 | 操作记录与访谈，不只看总时长 |
| 运行成本 | 模型 token、工具执行时间、远程环境和存储消耗 | 请求事件、工具计时和平台账单 |
角色与责任
| 角色 | 必须拥有的决定 | 不应被转嫁的责任 |
|---|---|---|
| 业务负责人 | 任务边界、完成定义、例外和最终验收 | 让模型自己定义业务正确性 |
| 产品/流程负责人 | 人工接管、审批文案和交付界面 | 用提示词掩盖未定义流程 |
| 平台工程 | preset、能力提供方、持久化和可观测性 | 替业务系统发明授权与事务语义 |
| 安全与合规 | 数据分类、执行环境、凭据和保留政策 | 把会话日志存在等同于合规完成 |
| 评估负责人 | 样本、人工基线、失败分类和阈值 | 只用单一平均分隐藏高风险失败 |
扩展、修正或停止
何时扩展？
当前任务在规定样本上达到退出条件，主要失败可分类和接管，控制分支经过真实演练，新增场景能复用现有运行主干。
何时修正？
价值存在但证据链断裂、工具接口不稳定、审批负担过高或某类失败集中出现时，先修流程、工具或组装，再重复同一阶段。
何时停止？
完成定义长期无法达成、不可逆动作不能拆分、数据与身份条件不允许、人工接管成本高于任务价值，或价值只能依赖无法验证的未来假设时停止。
先证明“可判断、可控制、可接管”，再证明“更快、更多、更自动”
Harness 的插件和多 Agent 能力很容易扩展范围。试点的纪律是让每次扩展都对应一项已经通过的证据，而不是用更多功能掩盖前一阶段没有解决的问题。
证据状态：本页的 Harness 能力与限制基于当前源码已确认；阶段设计、指标和组织建议属于试点方法，需要由目标企业设置样本与阈值。