5.1 六步实践路径
引言：从想法到工程的阶梯
前面讲了架构、工具、安全、成本——都是"该怎么设计"。这一节回答"该怎么落地"。
来源：Mitchell Hashimoto（HashiCorp 联合创始人）的实践经验。他不是理论派，是把 Agent 从玩具做成生产系统的人。
核心理念
不要试图一步到位。从最简单的确定性任务开始，逐步扩大 Agent 的自主范围——每一步都要有工程化保障。
第一步：放弃聊天机器人
大多数人第一次用 Agent，都是在聊天框里对话。这是最自然的方式，也是最不可工程化的方式。
聊天机器人的问题：
- 没有可重复性——同样的输入，不同时间可能得到不同输出
- 没有可审计性——对话散落在历史记录中，无法追溯
- 没有可组合性——无法与其他系统集成
替代方案：把 Agent 变成 CLI 命令、脚本或 API。输入和输出都是结构化的，可以被版本控制、CI/CD 和监控系统集成。
第二步：复现自己的工作
在让 Agent 做新事之前，先让它做你已经在做的事。
为什么？因为你已经知道正确答案，可以立即判断 Agent 做得对不对。这是建立信任最快的方式。
实践方法：
1. 记录你最近一周的工作
2. 选一个重复性最高的任务
3. 把它写成 Agent 工作流
4. 对比 Agent 输出和你的手动结果
5. 逐步修正，直到 Agent 稳定复现第三步：日末 Agent
每天下班前，让 Agent 做一件低风险但有价值的事：
- 总结今天的代码变更
- 检查是否有遗漏的 TODO
- 生成明天的待办清单
- 运行一遍代码质量检查
关键：日末任务的风险低——即使 Agent 做错了，你第二天上班也能发现和修正。这是在低风险场景下积累经验。
第四步：外包确定性
Agent 最擅长处理规则明确、步骤确定的任务。这类任务不需要创造力，只需要可靠性。
适合外包的任务类型：
- 代码格式化、lint 修复
- 测试用例生成
- 文档更新
- 配置文件迁移
- 依赖版本更新
不适合外包的任务：需要判断力的决策、需要领域知识的架构设计、需要人情味的沟通。
第五步：工程化 Harness
前四步都是在"用 Agent"，这一步开始"建 Harness"。
把前四步中的护栏、验证、权限控制抽象成可复用的工程组件：
| 组件 | 作用 | 来源 |
|---|---|---|
| 输入验证器 | 检查 Agent 输入的合法性 | 第二步中的边界检查 |
| 输出校验器 | 校验 Agent 输出的正确性 | 第二步中的对比验证 |
| 权限控制器 | 限制 Agent 的操作范围 | 第四步中的范围约束 |
| 监控仪表盘 | 实时查看 Agent 运行状态 | 第三步中的日末检查 |
第六步：始终有 Agent 在跑
这是终极目标：你的系统中始终有 Agent 在运行——不是偶尔用一下，而是持续工作。
- 代码仓库有 Agent 在做 PR Review
- CI/CD 有 Agent 在做质量检查
- 文档有 Agent 在保持更新
- 监控有 Agent 在异常告警
到这一步，Agent 不再是"工具"，而是"团队的一部分"。
本节小结
📌 本节核心要点
- 六步是渐进路径：放弃聊天 → 复现工作 → 日末任务 → 外包确定性 → 工程化 → 始终运行
- 每一步都建立在前一步的信任基础上——不要跳步
- 核心原则：先低风险后高风险，先确定性后创造性，先手动后自动
思考题
- 你目前在六步中的哪一步？下一步最大的障碍是什么？
- "复现自己的工作"——你哪个重复性任务最适合交给 Agent？画出它的工作流。
- 如果始终有 Agent 在跑，你需要什么样的监控和告警系统？
下一节预告
六步路径有了，具体到 Claude Code 怎么落地？下一节给你实操指南。