生产级 Agent：用户、任务与成功标准

“帮我研究这个主题”还不够作为完成标准。需要进一步确认交付物、资料范围和判断质量的方法。先把这些问题说清，后面的计划、工具和评测才有共同依据，而不只是看回答是否流畅。

1. 从问题定义开始

先写清：

  • 谁使用；
  • 在什么场景；
  • 输入是什么；
  • 期望产物；
  • 可接受时间与成本；
  • 哪些动作有副作用；
  • 人工在哪些节点参与；
  • 成功如何验证。

“做一个通用 Agent”缺少任务分布，无法选择工具、Memory 和 Eval。

2. Success Contract

yaml
user: repository maintainer
task: fix a failing unit test
inputs:
  - repository
  - failure log
outputs:
  - scoped code changes
  - test evidence
  - change summary
checks:
  - target test passes
  - no unrelated files changed
  - build remains valid
limits:
  - max 20 tool calls
  - max 15 minutes
confirm:
  - pushing remote branch

成功标准分为机器检查、模型 rubric 和人工验收。尽量把关键事实放到机器检查。

3. 产品边界

  • 支持的任务类型；
  • 不支持的输入格式；
  • 数据新鲜度；
  • 可用工具和资源范围；
  • 单任务预算；
  • 并发与排队；
  • 保留和删除策略；
  • 失败时向用户展示什么。

边界进入 UI、文档、prompt、权限和测试，而不是只写 README。

4. 渐进上线

Text
offline eval
  -> internal shadow
  -> read-only assistant
  -> reversible actions with confirmation
  -> limited automation
  -> broader rollout

每阶段有成功率、错误率、成本和风险门槛。先观察建议质量，再开放副作用动作。

5. 用户体验

  • 显示当前阶段和已完成事项；
  • 对长任务提供进度与取消；
  • 对确认动作显示精确影响；
  • 部分成功明确列出未完成项；
  • 提供证据和 trace 摘要；
  • 恢复后说明从哪个检查点继续；
  • 错误信息给出可行动下一步。

把“完成”改写成能观察的结果

用“整理工单”做需求时，可以先缩成一个可验收任务：“找出本周未关闭工单，给出编号、负责人和来源链接，不修改工单。”这样你马上知道需要只读查询、时间范围和引用检查，不需要先做自动分派系统。

下一步加入一条失败条件：如果权限不足或查询失败，应说明查不到的范围，不得把它写成“本周没有工单”。再加取消按钮和预算上限，检查它们是否真的作用到运行过程。

运行框架能帮你执行循环，但用户关心的是产物是否满足约定。把成功检查放在模型回答之外：编号存在、时间范围正确、没有写操作。检查通过后，再让模型组织可读的说明。

本节的核验依据

2026-10-25 查阅。下面的链接支持本节的机制说明；练习场景和选型建议是本教程的教学设计。