Agent 工作方法论：跨公司资料提炼
本文把 Anthropic、OpenAI 及 Agent 编程工具团队的公开资料压缩成一套可直接使用的工作方法。
一句话原则
让 Agent 负责推理和执行，让系统负责边界和验证，让人只在真正需要判断的节点介入。
1. 先判断：这是不是 Agent 问题
优先级从低到高：
- 单次模型调用：任务简单、输入输出稳定。
- 检索 + 单次调用：需要知识，但步骤稳定。
- 固定工作流：可预先分解，有明确中间检查点。
- Agent：步骤数量、工具选择或路径无法预先写死。
- 多 Agent：不同角色确实需要不同工具、权限、标准或上下文。
如果增加 Agent 后只是增加成本、延迟和不可预测性，就不要增加。
2. 一份好的 Agent 任务说明
目标：最终要交付什么
用户：谁会使用结果，结果用于什么决定
背景：已有资料、代码、数据、历史状态
范围：可以访问和修改什么
工具：每个工具的用途、参数、限制和失败方式
约束：时间、预算、风格、合规和安全限制
验收：如何判断结果完成且正确
审批：哪些动作必须先询问人
交付：结果、证据、验证记录、遗留风险3. 让 Agent 形成闭环
理解任务
→ 探索相关上下文
→ 形成计划
→ 执行一个小步骤
→ 读取真实环境结果
→ 对照验收标准
→ 修正或继续
→ 汇总结果与证据最常见的失败是缺少最后三步：Agent 做了修改，但没有验证；用户看到文本，却不知道是否真的工作。
4. 选择工作流模式
| 模式 | 适合 | 常见例子 |
|---|---|---|
| Prompt chaining | 固定步骤 | 提取 → 分类 → 写作 |
| Routing | 输入类型差异明显 | 技术问题/账单问题/安全问题分流 |
| Parallelization | 子任务独立或需要多视角 | 多来源研究、代码审查 |
| Orchestrator-workers | 子任务无法预先确定 | 大型代码变更、复杂研究 |
| Evaluator-optimizer | 有清晰评价标准 | 文案、代码、结构化报告迭代 |
| Autonomous agent | 开放问题、路径未知 | 调查、调试、浏览和工具操作 |
5. 工具设计原则
- 工具名称和描述要让模型知道“什么时候该用”。
- 输入参数尽量窄，输出尽量结构化。
- 明确权限、成本、延迟和副作用。
- 失败返回可行动信息，不要只返回“失败”。
- 读操作与写操作分离。
- 删除、付款、发布、发信、改权限等动作必须有审批或硬限制。
- 为重复调用设计幂等键、超时、重试和回滚。
6. 上下文管理
- 只加载当前任务需要的资料。
- 将稳定规则放进项目配置、记忆或 skills，而不是每次重复粘贴。
- 长任务分阶段，并在阶段末保存状态摘要。
- 把探索、实现、验证和复核拆开，避免一个上下文无限膨胀。
- 对多 Agent 只传递必要的任务上下文和结构化结果。
7. 验证与评估
每个 Agent 任务至少设计一种可读信号：
- 测试通过/失败；
- 构建退出码；
- Schema 校验；
- 截图或输出对比；
- 引用完整性；
- 数据库状态；
- 外部 API 回执；
- 人工审批结果。
生产化前至少记录：成功率、错误类型、工具失败率、成本、延迟、人工接管率、安全事件和用户满意度。
8. 人机协作边界
| 风险 | Agent 可自动做 | 应暂停询问 |
|---|---|---|
| 低 | 搜索、整理、草拟、运行测试 | 通常不需要 |
| 中 | 修改代码、批量变更、发起内部流程 | 范围不清、影响较大时 |
| 高 | 发布、付款、删除、发信、改权限 | 默认需要人工确认 |
| 极高 | 生产数据破坏、资金转移、法律/医疗决定 | 必须人工主导 |
9. 最小可行实践
从一个窄任务开始：
- 选一个每周重复、验收标准清楚的任务。
- 让 Agent 先只读探索和出计划。
- 给它 2–5 个最必要的工具。
- 加一个自动验证命令或结构化检查。
- 保留人工审批节点。
- 记录 20–50 个真实任务，判断是否真的节省时间。
- 只有在数据证明有效后，才增加自治、多 Agent 或更多工具。
最值得记住的结论
- Anthropic：从简单可组合模式开始，复杂度必须用结果证明自己。
- Claude Code：给 Agent 验证信号，并管理上下文。
- OpenAI：先定义单个 specialist，再按需要做编排、guardrails、状态和评估。
- 共识：Agent 的上限取决于工具、上下文、验证和边界，不只是模型本身。