基于目标的 Agent
🏦 场景与客户
某企业 IT 部门的工单治理。目标写得很清楚：把某系统积压的未闭环工单压到某个量级以下，期限一个季度。过去这件事靠专人盯，人一忙就停摆。
客户要的是让系统自己拆任务——查存量、定分派、催办、核实——而不是每天早上给人推一张待办清单。
📅 实施节奏
- 第 1–2 周：把目标写成可度量的指标，明确阈值、期限与验收口径
- 第 3–4 周：让 Agent 先出拆解计划，人工评审可行性后再执行
- 第 5–6 周：接入工单系统的读与写权限，先在只读范围内跑
- 第 7 周起：放开受限写操作，加断点续跑与人工接管
🗝️ 方案要点
- 目标必须可度量：写成指标 + 阈值 + 期限，写不出来的目标不交给 Agent
- 拆解与执行分离：先出计划让人确认，再动手，避免方向错了跑得越远
- 每步可观测：状态变化随时可查，不是黑盒等最终结果
- 允许认输：明确尝试多少次后停止并报告卡点，不无限重试
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 目标定义 | 量化指标 | 可验收；代价是不好量化的价值被排除在外 |
| 计划确认 | 执行前人工确认 | 安全；代价是失去全自动带来的时效优势 |
| 搜索深度 | 限制尝试次数 | 成本可控；代价是难任务可能提前放弃 |
| 偏航纠正 | 定期回看目标 | 能纠偏；代价是增加判断开销与延迟 |
🚧 实施难点与排查
- 目标被刷：挑软柿子凑指标。加质量约束，不只看数量
- 目标冲突：压工单量与满意度打架。提前明确优先级，不让 Agent 自己权衡
- 计划幻觉：拆出的步骤在系统里做不到。执行前先做一步可行性校验
- 长链路失败：跑到一半环境变了。加断点续跑与重规划，不用从头再来
💵 成本与收益
- 成本：调用量与尝试次数正相关，长任务成本不可忽略，需设单任务预算
- 收益：把「有人盯才动」变成「自己会动」，人只处理卡点
- 注意：这类 Agent 的价值高度依赖目标定得对不对，目标错则越跑越偏
🛡️ 风险与保障
- 权限：只给达成目标所需的最小权限，写操作单独审批
- 熔断：预算或尝试次数超限立即停止
- 可回滚：批量写操作前留快照，异常时可还原
- 汇报：定期向责任人同步进度与风险，避免静默失败
♾️ 可复用与演进
- 可复用到数据治理、库存清理、内容补全等有明确终点的任务
- 演进方向：从单目标到多目标带权重
- 再进一步：沉淀目标库，常见目标直接套用既有的拆解模板
