三类 Agent 端到端案例：研究、客服与软件工程

学完 Loop、Harness、Memory、多 Agent、协议、Eval 和安全之后，最容易出现另一种问题：概念都懂，但不知道在具体系统里哪些组件真的需要。

这一讲选择三类差异很大的任务：：深度研究、企业客服、软件工程：：用同一套问题逐一设计：终态是什么，状态怎样走，需要哪些工具，是否需要 Memory 和多 Agent，怎样评测，最大风险在哪里。

案例不是可直接采购的“标准架构”，而是把 23 篇知识组合成工程决策。

一、统一设计模板

无论什么 Agent，先填写八项：

Goal：用户真实目标
Terminal State：可验证终态
State：运行中必须持久化的事实
Tools：读取与副作用能力
Control：固定流程、模型决策与人工节点
Memory：跨轮与跨会话信息
Evidence：成功和安全的证据
Limits：时间、费用、权限和影响范围

如果“Terminal State”只能写成“模型认为已经完成”，设计还没结束。

二、案例一：带来源的深度研究 Agent

1. 目标与边界

用户要求调研一个快速变化的技术主题，输出可读报告、来源链接、事实核对日期和争议点。

它不是“搜索后写长文”。真正终态是：关键问题都被证据覆盖，动态事实有日期，引用能打开，结论能追溯到来源，未解决冲突被明确披露。

2. 建议状态机

INTAKE
  -> RESEARCH_PLAN
  -> SOURCE_DISCOVERY
  -> EVIDENCE_EXTRACTION
  -> GAP_CHECK
  -> SYNTHESIS
  -> CITATION_VERIFY
  -> READY / PARTIAL / NEEDS_HUMAN

GAP_CHECK 很重要。没有它，Agent 常在找到几篇支持相同观点的文章后提前停止。

3. 工具设计

• 搜索：发现候选来源；
• 浏览器/抓取：读取官方页面和论文；
• GitHub API：动态仓库元数据；
• PDF 读取：论文和白皮书；
• 引用注册表：保存标题、URL、时间和用途；
• 链接验证器：核对最终引用；
• 文件工具：写研究笔记和正文。

浏览器框架如 Browser Use 能帮助处理开放网页，但研究 Agent 不应继承个人浏览器的全部登录态和本地文件。[1]

图 1：Browser Use 代表开放网页 Agent。用于研究时仍需来源政策、沙箱和引用验证。来源见文末。

4. 是否需要多 Agent

只有在主题支线能并行、资料量很大时才拆。可以让多个 Research Worker 分别处理课程、框架、协议和安全，每个只返回证据卡；主编负责冲突图和叙事。

不要设置“夸夸 Agent”和“反对 Agent”进行无证据辩论。真正的独立性来自不同来源和验证方法。

5. Context 与 Memory

当前任务 Context 包含研究问题、证据卡、术语表和缺口，不把所有网页全文重复送入每轮。

长期 Memory 只保存用户稳定偏好，例如读者水平、文风和禁用图示；动态事实仍从来源重新核对，不能把旧 Star 或旧规范版本当永久记忆。

6. Eval

• 来源覆盖率；
• 一手来源比例；
• 引用可访问率；
• 主张：证据一致性；
• 动态事实日期完整率；
• 争议与局限是否披露；
• 每个完成报告成本和人工核对时间。

模型 Judge 可以评可读性，引用和日期更适合确定性检查。

三、案例二：企业客服与退款 Agent

1. 目标与边界

用户要解决订单问题。系统要读取订单、解释政策、必要时提交退款或转人工。

高风险终态不是“回复用户已退款”，而是订单和支付系统出现可查询的退款记录，金额、原因和用户身份匹配，同时没有越权访问其他租户。

2. 建议状态机

IDENTIFY_USER
  -> CLASSIFY_INTENT
  -> LOAD_ORDER
  -> CHECK_POLICY
  -> DRAFT_ACTION
  -> APPROVAL_IF_REQUIRED
  -> EXECUTE_WITH_IDEMPOTENCY
  -> VERIFY_ORDER_STATE
  -> INFORM_USER / ESCALATE

固定政策检查和执行边界应由代码/规则控制，模型负责理解表达、提取参数和生成解释。

3. 工具设计

read_order(order_id)          只读
read_policy(region, date)     只读
create_refund_draft(...)      可逆草稿
execute_refund(..., idem_key) 高风险写
query_refund(idem_key)        终态查询
escalate(case)                人工队列

不要给一个通用 run_sql 让模型自己拼业务查询，也不要把资金操作与政策说明混在同一个宽泛工具里。

4. 是否需要多 Agent

大多数客服流程用一个对话 Agent 加受控工具和状态机已经足够。只有多领域分流明显时，才用 Handoff 转给物流、账单或技术支持 Agent。

资金动作可以设计为独立执行服务或审批节点，但它未必需要另一个语言模型。把权限交给确定性服务，往往比增加“退款 Agent”更清楚。

5. Memory

会话内记住订单号和已确认事实；跨会话可保存用户明确偏好，但订单状态必须实时查询。

“用户上次获准特殊退款”不能自动成为永久政策。Memory 必须区分事实、历史事件与当前授权。

6. 可靠性与安全

• 每次退款使用业务幂等键；
• 超时后按键查询，不盲目重试；
• 身份与租户在后端再校验；
• 金额和目标绑定人工批准；
• Policy 版本写入 Trace；
• 外部邮件和聊天内容标为不可信；
• 任何未知状态进入人工，而不是向用户谎报成功。

7. Eval

构造待发货、已发货、部分退款、跨租户、金额上限、政策过期、支付超时和间接注入 Case。硬指标包括终态正确、零重复退款、零跨租户访问和批准绑定率。

这类系统的安全通过率不能被平均满意度抵消。

四、案例三：软件工程 Coding Agent

1. 目标与边界

用户要求修复一个真实 Issue。终态至少包含：补丁仅修改允许范围，相关测试通过，静态检查通过，当前 Git Tree 与证据绑定，已知风险和未运行测试被披露。

Coding Agent 的动作空间比客服更开放：读写文件、运行任意命令、下载依赖、使用浏览器、访问 Git 和 CI。这决定了它必须有隔离 Runtime。

OpenHands 把 Agent 与 Runtime、终端、浏览器和产品界面组合成完整软件开发环境。[2]

图 2：OpenHands 是高关注开源 Coding Agent 平台之一，展示了模型之外的执行环境需求。来源见文末。

2. 建议状态机

ISSUE_INTAKE
  -> REPO_INSPECTION
  -> REPRODUCE_FAILURE
  -> PLAN_PATCH
  -> EDIT_IN_SANDBOX
  -> RUN_TARGETED_TESTS
  -> RUN_GUARDRAILS
  -> INDEPENDENT_VERIFY
  -> PROPOSE_DIFF / NEEDS_HUMAN

“先复现”是关键 Gate。不能复现时，Agent 应记录假设和缺失环境，不应直接大范围改代码。

3. 工具与沙箱

• 仓库只在临时工作树中写入；
• 终端有 CPU、内存、时间和进程限制；
• 网络默认受限，安装依赖经过允许源；
• Secret 通过短期句柄提供，不进入模型；
• 文件 Tool 限制仓库根目录；
• Git Diff 和测试报告作为工件保存；
• 默认只提出补丁，不自动合并或发布。

4. 单 Agent 还是多 Agent

小型修复通常一个 Agent 更高效。大型仓库可以并行：一个 Worker 定位调用链，一个查历史 Issue，一个建立测试；实现仍由唯一 Writer 完成，避免多个 Agent 同时修改同一树。

高风险变更需要独立 Review Session，最好由不同上下文读取 Diff 和测试证据，而不是让原实现 Agent 自评。

5. Context 与 Memory

Context 应优先包含 Issue、相关代码、测试失败、仓库规则和当前 Diff，不要把整个仓库塞入模型。

跨任务 Memory 可以保存仓库约定和已验证命令，但必须绑定仓库与版本。旧分支上的经验不能覆盖当前代码事实。

6. Eval

SWE-bench 使用真实 GitHub Issue 和测试评估软件工程能力，是外部坐标之一。[3] 内部还要建立自己的仓库 Case：构建失败、回归测试、路径限制、依赖安全、超时和不可复现问题。

核心指标：Issue 解决率、测试证据新鲜度、错误修改范围、人工 Review 时间、每个接受补丁成本，以及安全事件。

五、三个案例为何不能共用一套“万能 Agent”

维度	深度研究	企业客服	Coding Agent
主要终态	证据覆盖的报告	业务系统订单状态	当前代码树与测试
动作风险	主要是信息错误	资金与客户数据	文件、命令、供应链
控制重点	来源、缺口、引用	身份、政策、幂等	沙箱、Diff、验证
Memory	偏好可长期，事实重查	偏好与历史，状态实时	仓库规则，绑定版本
多 Agent 价值	并行研究	专业 Handoff	独立调查与审查
人工节点	争议结论	高风险资金动作	合并、发布与高风险变更

同一个基础模型可以参与三者，但 Harness、工具、状态和 Eval 必须不同。这正是第 2 讲“模型之外的系统”在案例中的体现。

六、协议怎样落位

研究 Agent

用 MCP 连接搜索、浏览器、GitHub 和文档；若委派给外部专业研究服务，可考虑 A2A；前端用类型化事件显示来源收集和引用核对。

客服 Agent

业务 API 或 MCP 连接订单与政策，但后端必须再授权；Handoff 在组织内部转给账单 Agent；AG-UI 类事件可显示审批和处理进度。

Coding Agent

ACP 连接编辑器与 Agent，MCP 连接仓库/Issue/浏览器，A2A 可委派独立安全审计；所有协议之上仍有仓库身份、沙箱和合并政策。

协议负责接口，领域状态机负责用户终态。

七、从零实现时怎样分阶段

第 1 周：窄任务和终态

只选一个子任务，写 20 个真实 Case 和确定性终态。工具先用 Mock 验证控制流。

第 2 周：最小 Tool 与 Trace

接一个只读工具，记录模型、参数、结果和版本。建立失败分类。

第 3 周：受控副作用

只开放草稿或沙箱写入，增加 Policy、幂等、检查点和验证器。

第 4 周：影子与小流量

重放真实脱敏任务，按风险切片观察成功、人工接管、延迟和成本。证据不足就保持草稿模式。

不要在第一周同时加入多 Agent、长期 Memory、十个 MCP Server 和自动写权限。那会让失败无法归因。

八、20：40 分钟实践：为一个案例写最小设计

任选上述一类，用一页 Markdown 回答：

1. 用户目标和三种非目标；
2. 机器可验证终态；
3. 5：8 个状态；
4. 每个 Tool 的输入、输出、错误和风险；
5. 哪一步由模型决定，哪一步由代码决定；
6. 两个权限边界；
7. 五个 Eval Case，其中两个必须是失败或攻击；
8. 一个超时后的恢复流程；
9. 一个明确人工节点；
10. 上线前不做的功能。

然后用第 23 讲选出的框架实现最小状态机。只接 Mock Tool，先跑通成功、确定性拒绝和未知外部状态三条路径。

九、三个案例的共同底线

尽管架构不同，它们共享六条底线：

• 目标有环境终态；
• 模型不能自己授予权限；
• 工具调用有 Schema 与业务政策；
• 长任务有预算、持久状态和恢复；
• 执行者不能只靠自述证明完成；
• 新失败进入 Eval，形成持续改进闭环。

十、这一讲的结论

Agent 系统不存在脱离任务的标准答案。研究 Agent 的核心是证据，客服 Agent 的核心是身份与业务终态，Coding Agent 的核心是隔离环境、代码证据和变更控制。

框架、Memory、多 Agent 和协议都只是实现手段。先明确终态和最大风险，再选择最小必要组件，系统才有机会从 Demo 走到生产。

下一讲收束整套连载：Agent 技术接下来可能向哪里演进，哪些方向证据已经较强，哪些仍是推测，以及怎样用 12 周建立可持续学习路线。

---

参考资料

[1] Browser Use. https://github.com/browser-use/browser-use

[2] OpenHands. https://github.com/OpenHands/OpenHands

[3] Jimenez et al., SWE-bench. https://arxiv.org/abs/2310.06770

[4] OpenAI, A practical guide to building agents. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

[5] Google Cloud, A developer’s guide to production-ready AI agents. https://cloud.google.com/blog/products/ai-machine-learning/a-devs-guide-to-production-ready-ai-agents/

[6] Sierra Research, τ-bench. https://tau-bench.com/