《How to build an AI agent: from one prompt to a production setup》—— 70+ 篇一线工程博客的归纳总结
文章开篇没有讲理论，先甩了三个生产数字：
关键洞察是：这些公司用的不是"一个万能 agent"，而是一组针对不同任务专门设计的 agent。每个 agent 职责窄、工具少、护栏清晰。这正是全文的立论起点：生产级 agent 的核心竞争力在分工与外围工程，而不在模型本身。
文章引用了两家最具代表性的定义：
但文章真正想说的是下一句：各家公司真正投入数月打磨的，从来不是这三个要素，而是包在外面的 harness。模型可以换，harness 才是资产。
所谓 harness，就是让 agent 在生产环境里"不闯祸、能干活、可追溯"的那一整套外围工程。文章归纳出六个必备组件：
| 组件 | 做什么 | 为什么重要 |
|---|---|---|
| 循环（Loop） | 调用模型 → 执行工具 → 把结果喂回模型 → 重复，直到任务完成或触发停止条件 | 这是 agent 的"心跳"；没有稳健的循环控制，agent 会无限打转或中途泄气 |
| 上下文与记忆 | 管理有限的上下文窗口：该记住什么、该压缩什么、该忘掉什么 | 长任务里上下文是稀缺资源，管理不好就会"失忆"或"老年痴呆" |
| 沙箱隔离 | 给 agent 一个隔离的执行环境（容器/虚拟机/独立分支） | 再聪明的 agent 也会犯错，沙箱保证犯错的代价可控 |
| MCP 工具网关 | 通过统一网关接入工具，而不是让每个 agent 直连一堆 API | 工具的权限、审计、限流在这里集中管，是安全的基本盘 |
| 护栏（Guardrails） | 默认只读、花费上限、高风险操作强制人工审批 | 生产环境的"安全带"，也是和业务方建立信任的前提 |
| 验证（Verification） | 测试、lint、再派第二个 agent 独立检查产出 | 对应后文规则一：干活的不许自己打分 |
文章花了一节澄清这对最容易混淆的概念：
生产实践的结论是两者混合：用 workflow 框住确定性的骨架，把真正需要判断的节点交给 agent。Stripe 内部把这种混合体叫做 blueprints。记住这个词，它代表了目前大厂的主流答案 —— 不是"全 agent 化"，而是"该确定的确定，该灵活的灵活"。
把 70+ 案例拆开看，agent 的组织方式无非五种。认出模式，就能快速给新任务选型：
| 模式 | 长什么样 | 适合哪类任务 |
|---|---|---|
| Prompt chaining 提示链 | 把任务拆成固定顺序的步骤，前一步的输出是后一步的输入 | 步骤清晰、顺序固定的流水线（如：生成 → 检查 → 改写） |
| Routing 路由 | 先分类，再把任务分发给专门的子处理单元 | 输入类型多、但每类处理方式明确（如客服工单分诊） |
| Parallelization 并行化 | 把任务切成互不依赖的子任务，同时跑，最后汇总 | 可拆分的批量工作（如多文件迁移、并行搜索） |
| Orchestrator / Workers 调度器与工人 | 一个主 agent 负责规划拆解，多个 worker 并行执行，主 agent 汇总 | 复杂、动态的任务（深度研究、大型重构） |
| Evaluator / Optimizer 评估与优化 | 一个生成、一个评估打分，循环迭代直到达标 | 质量要求高、可明确定义"好"的任务（如文案、代码） |
这是全文最有警示价值的一节。文章的建议很干脆：先把单个 agent 用好，只有当指令开始缠绕、工具互相重叠时，才考虑拆分。
反面教材是微软 Azure SRE Agent 的第一版：100+ 工具、50+ 子 agent，看起来很强大，实际效果是 —— 凡是需要超过 4 跳传递的任务，几乎必失败。信息在层层转述中衰减、失真，最后产出不可用。重构之后，只保留了数个通用 agent 和 5 个核心工具，反而 work 了。
拆分的判断标准可以记成一句话：当你发现一份指令里塞了互相冲突的职责，或者一个 agent 的工具列表长到它自己都记不清时，就是拆的时候。
每一种方案，原文都按四个维度展开：是什么、怎么建、谁在用、从哪起手。下面是精读提炼。
是什么：工程师在 Slack 或 ticket 里派活，然后就可以离开；回来时 PR 已经准备好了。Agent 在独立环境里写代码、跑测试、推分支，全程异步。
谁在用：Stripe 的 Minions（每周 1000+ 个合并 PR，背后是内部 MCP 服务器 Toolshed 统一供给工具）；Spotify 的 Honk（配了一个 LLM judge，大约 1/4 跑偏的任务会被否决掉）；Shopify 的 River（每 8 个合并 PR 就有 1 个由 agent 联合撰写，30 天 3536 个）。
怎么建：关键在"派活接口"（Slack/ticket 触发）+"隔离执行环境"（独立分支/容器）+"自动化的质量门"（测试必须过，judge 负责否决）。人只负责派活和最终合并。
从哪起手：挑一类重复的小 ticket（修文案、加日志、补单测），先让 agent 在只读+独立分支里跑，人工合并。
是什么：在人工 reviewer 之前，先把所有 PR 过一遍的评审 agent。不是替代人，而是把人的注意力留给真正难的问题。
谁在用：Cloudflare（按风险分级，最多派 7 个评审视角，一个月 13 万次评审，中位成本 $0.98）；DoorDash（60.2% 的高危发现最终导致了代码变更 —— 说明不是在刷存在感）；Uber 的 uReview（75% 的评论被工程师评为"有用"）。
怎么建：核心是"风险分级"：低风险 PR 轻量过、高风险 PR 多视角深挖。评审意见必须可执行、可定位到代码行，泛泛而谈的评论会被工程师无视。
从哪起手：先给最成熟的仓库接上，只做"找 bug"不做"挑风格"，用"导致变更率"衡量效果。
是什么：在成千上万处代码里应用"同一种无聊改动"的 agent：升级依赖、迁移测试框架、清理过期 flag。人类最烦、agent 最擅长的活。
谁在用：Airbnb（3500 个测试文件迁移，人工估计要 1.5 年，实际 6 周干完）；Google（JUnit3 迁 JUnit4，5359 个文件，3 个月）；DoorDash（清除过期 feature flag，50 个里 45 个可直接合并）。
怎么建：这是 parallelization 模式的教科书案例：任务天然可拆、单点改动小、验证标准明确（测试全过即成功）。配上批量 PR + 人工抽查合并的流程。
从哪起手：找你们代码库里"同一改动超过 500 处"的那件事，就是它。
是什么：告警一响就接入排查的 agent：拉日志、查指标、定位根因。默认只读，真正要执行修复动作时，必须人工按键确认。
谁在用：微软 Azure SRE Agent（9 个月独立处理 35000+ 事件，某服务的平均 MTTR 从 40.5 小时降到 3 分钟）；Ramp 的 OCA；Meta 也有同类实践。
怎么建：护栏是生命线：排查阶段只读、可观测性工具（日志/指标/trace）通过 MCP 网关统一供给；修复动作分级，重启服务这种一律人工确认。MTTR 是唯一的北极星指标。
从哪起手：先接"只读诊断"：告警触发后自动出一份根因分析报告，人来做决策。
是什么：三件事：告警分诊、挖漏洞、起草修复方案。安全场景对"证据"的要求最高，模型不许空口断言。
谁在用：Cloudflare（证据包先行于模型结论，每一条引用都由代码校验过）；Figma（漏洞解决时间快了 71%）；Shopify 的 Dispatch（6 周 300+ 有效发现，折合约 40 万美元等值赏金）。
怎么建：核心设计是"证据先行"：先由普通代码收集证据包（调用栈、diff、依赖版本），模型只负责基于证据推理。引用必须可机器校验，这是安全 agent 与普通 agent 的最大区别。
从哪起手：从告警分诊开始：把安全告警按"真/假阳性"先分一遍，省下安全工程师的时间。
是什么：用自然语言问数，agent 自己写 SQL、查数、把结果和 SQL 一起交回来。SQL 必须附上 —— 这是可审计性的底线。
谁在用：DoorDash 的 Vera（覆盖 20 万+ 数据集，评估通过率从 43% 干到 90%）；Notion 的 Data Scout；OpenAI 内部 agent（3500+ 用户，背后 600 PB 数据）。
怎么建：最难的是"语义层"：表和字段的业务含义必须沉淀成知识，否则模型写出的 SQL 似是而非。通过率要用真实历史问题做回归评估，一点点磨上去（Vera 的 43%→90% 就是这么来的）。
从哪起手：先给最常用的 20 张表写好语义注释，再放 agent 上来。
是什么：不是"一个大模型回答一切"，而是一条成本阶梯：简单查询走确定性代码，常见问题走 RAG，只有复杂问题才上完整的 agent；再往下还有专家子 agent、护栏、LLM 评审，低置信度一律转人工。
谁在用：Lyft、DoorDash、Coinbase 的 CEEcil。
怎么建：这是 routing 模式的代表作。设计重点是"分流"而不是"回答"：80% 的问题不该进到 agent 那一层。每一层的转人工阈值要可调、可观测。
从哪起手：先统计你们重复问题 Top 20，用 RAG 挡掉，再谈 agent。
是什么：主 agent 负责规划拆解，多个工作 agent 并行搜索，最后压缩汇总、逐条核验引用。Orchestrator/Workers 模式的典型。
谁在用：Anthropic（Opus 做领队规划，Sonnet 做子 agent 执行；代价是 token 消耗约普通聊天的 15 倍）；Harvey（法律场景）；Perplexity Deep Research。
怎么建："引用核验"是独立的一步，不能省。成本意识要前置：15 倍 token 意味着必须用"小模型干活、大模型把关"的搭配，否则账单爆炸。
从哪起手：先定义"研究报告的验收标准"（覆盖面、引用格式、结论可溯源），再搭 pipeline。
是什么：把专家"没写下来、但天天在用"的经验，沉淀成 agent 可读的知识文件。agents 负责编写，critic 负责评审，事实有过期机制，出错后能自我修复。
谁在用：Meta 的 tribal knowledge 项目（4100+ 份散落文件整理成 59 个上下文文件）；Notion 的 Lore。
怎么建：关键在"写入-评审-过期"的闭环：知识不是一次写完的，要有 critic 持续评审质量，有过期机制淘汰失效经验，有"出错 → 回溯 → 修正知识"的自我修复链路。
从哪起手：找团队里"只有某个人知道"的那 10 件事，先沉淀下来。
是什么：cron 定时唤醒的 agent：每天早上查五个工具、出一份简报。只读访问，用 bookmark 记进度，内存分成"用户偏好"和"自身状态"，每轮有预算上限。
谁在用：Anthropic 的每日简报（每轮预算上限 $5）；GitHub Agentic Workflows；微软的定时任务实践。
怎么建：三个设计点：bookmark（下次从哪继续）、记忆分区（偏好 vs 状态分开存）、预算上限（防止半夜烧钱）。只读先行是铁律。
从哪起手：每天早上你手动查的那几件事，第一个自动化它。
把十种方案横向对比，文章提炼出六条所有生产级 agent 都遵守的规则。这是全文最值得背下来的部分：
文章结尾的选型建议非常克制，没有"都要做"，而是：只看"本周最让你烦的那件事"，选一个切入。
落地的口诀只有一句：Start narrow, read-only, with one checker on top —— 从窄切入、只读先行、头顶一个检查者。先让它在小范围里只读地跑、有独立检查者验收，跑顺了再放开权限、扩大范围。
原文最后一句，也是全文的题眼：The model is the easy part. The setup around it is what makes it work.
模型是最容易的部分，真正让它 work 的，是围绕它的那一整套东西 —— 循环、记忆、沙箱、网关、护栏、验证、分工、评估。这篇文章的价值，就是把"那一整套东西"拆成了十种可抄的作业和六条可背的规则。