AI Agent 不是先自动化，而是先练成可复用流程

先说结论

这期的核心观点很朴素，但对今天很多 Agent 项目都很关键：不要一上来就做“自动运行的智能体”。更稳的路径是先把任务当作人工协作流程来跑，用提示词和人工验证反复测试边界；等模式清楚之后，再沉淀成可复用的 skill；最后，只把已经有判断标准、可观测、可回滚、低风险的部分推到云端自动执行。中文深度整理，非逐字翻译。

原始来源：How I Approach Building AI Agents From Scratch。节目：Product Pathways。原始日期：2026-09-08。时长：约 5 分钟。内容类型：短讲 / AI Agent 产品方法。

这期内容在讨论什么

这不是一套模型架构教程，而是一套产品化顺序。讲者用“处理 bug”作为例子：当一个 bug 出现时，他不会立刻搭一个自动修复 agent，而是先把问题交给 Codex 一类工具做调查，同时自己也做独立验证。这个阶段的目标不是省掉人，而是看模型在真实任务里会如何理解问题、遗漏什么、需要怎样的追问，以及哪些判断仍然必须由人把关。

这种手动阶段很重要，因为 agent 一旦自动运行，就失去了很多临场追问和即时纠偏的空间。人工提示阶段反而是试验场：可以不断追问、修正、验证，再把真正有效的步骤留下来。

核心观点

第一，Agent 的起点不是自动化，而是手动原型。先用人工 prompting 跑几遍任务，观察模型在哪里有帮助、在哪里不可靠、需要哪些上下文、输出该如何验收。这个阶段看起来慢，但它是在为之后的自动化收集事实。

第二，稳定经验要沉淀成 skill。讲者的做法是，在完成几轮人工协作后，把整个过程复盘成可重复执行的技能：输入是什么，检查什么，怎样分类，哪些动作可以做，哪些情况要停下来问人。下一次遇到类似 bug，就不是重新提示一遍，而是调用已经沉淀过的 skill。

第三，skill 到 agent 之间还要有判断矩阵。比如把 bug 分成不同严重级别：低风险、明确的问题可以让系统自主修复；高风险、影响范围不清或判断复杂的问题，则必须交回给人。关键不在于矩阵长什么样，而在于自动化边界必须被写出来、测试过，并且能被纠正。

第四，真正上线前必须有可观测性和门禁。讲者强调自己希望所有 agent 动作都能被看见，甚至通过 Slack 接收大量通知。通知太多也会成为负担，但比“系统悄悄做了事而人不知道”更可控。更重要的是，agent 的输出不能直接进入生产，仍然要经过测试、流程和防护栏。

推理链与关键例子

这套方法背后的推理是：自动化不是把一次成功的提示词包装起来，而是把一个可验证的操作流程产品化。一次对话里模型表现不错，不代表它已经适合无人值守。只有当同类任务重复出现，且人已经知道怎样评价结果、怎样识别例外、怎样处理失败时，才有资格进入更自动的阶段。

以 bug 处理为例，第一轮可能只是让模型调查原因，人工同步验证；第二轮让模型尝试提出修复方案，人工判断是否合理；第三轮才可能让它修改代码并跑测试。每一轮都在产生新的规则：哪些日志必须看，哪些文件不能碰，哪些失败要升级，哪些修复模式可以复用。把这些规则写成 skill，本质上是在把人的经验变成可执行的操作说明。

然后才是 agent。Agent 不是更聪明的提示词，而是带有运行环境、触发条件、权限边界和反馈渠道的系统。把 skill 推到云端自动运行之前，需要先知道它适合处理哪类任务，不适合处理哪类任务。讲者提到的严重度矩阵就是这个作用：不是所有问题都交给 agent，也不是所有问题都交给人，而是让系统在清晰边界内行动。

边界、保留意见与争议

这期内容的一个重要边界是，它更适合讨论工程和产品团队内部的 agent 工作流，而不是面向终端用户的通用助手设计。内部场景有日志、代码、测试、Slack、审批和生产发布流程；这些基础设施能给 agent 提供较好的护栏。换到开放用户场景，风险会更复杂。

另一个边界是通知和可观测性本身也有成本。讲者说自己收到了大量 Slack 消息，甚至因此关闭过一些 agent。这个细节很真实：可观测不是越多越好，而是要能帮助人做判断。如果所有事件都推送，最后人会失去注意力；如果关键事件不推送，系统又会变成黑箱。

最后，讲者也承认这只是当下阶段的经验。AI 工具变化很快，便宜模型、本地模型、云端 agent、技能系统和自动化平台都还在演进。可复用的不是某个具体工具，而是“先人工验证，再沉淀流程，再有限自动化”的顺序。

整理后的观察

这期最值得留下来的不是“如何搭 agent”，而是“如何不急着搭 agent”。很多失败的自动化项目，问题不在模型能力太弱，而在团队太早跳过了流程发现阶段。还没有稳定判断标准，就把任务交给自动系统；还没有可观测性，就让系统默默执行；还没有异常处理，就期待它自主收尾。这些都会把 agent 从效率工具变成风险放大器。

更实际的做法，是把 agent 建设当成一个渐进式产品过程。第一步是人工协作，目标是理解任务；第二步是 skill，目标是稳定复用；第三步才是 agent，目标是让低风险、判断明确、反馈闭环清楚的部分自动运行。

如果把这套方法放到团队管理里，它也给出了一个很好的成熟度模型：能不能把人的判断写成规则，能不能把规则放进可执行流程，能不能让流程在边界内自动运行，并且在越界时及时回到人手里。Agent 的价值不只是“少一个人操作”，而是让组织逐步把隐性的经验变成显性的系统能力。