智能体需要操作手册，而不是更长的对话

论点：生产级智能体不会因为我们写出更好的提示词而变得可靠。它们变得可靠的前提是：我们给予它们与人类相同的运营脚手架：操作手册、权限、日志、回滚和验证。

如果你的智能体工作流程依赖这样的话术：

重要提示： 请勿跳过此步骤****请确保进行验证 您必须按照计划执行

那么你不是在构建一个智能体系统。

你是在与一个随机的实习生谈判。

演示阶段这样还行。 生产环境就会出问题。

因为真正的工作不是单个提示词。

真正的工作是：

• 阅读问题
• 检查代码库
• 理解现有规范
• 进行修改
• 运行测试
• 调试失败
• 更新计划
• 检查差异
• 请求批准
• 创建 PR
• 监控 CI
• 响应审查
• 必要时回滚

这不是“聊天“。

这是一个运营循环。

而运营循环需要操作手册。

而不是感觉。

我们在 DevOps 中已经学过这一课

在 DevOps 成熟之前，很多基础设施工作存在于人们的头脑中。

部署是部落知识。

事件响应是 Slack 混乱。

生产调试意味着找到那个知道该 SSH 到哪台服务器的高级工程师。

然后我们慢慢把工作转移到系统中：

• 操作手册
• CI/CD 流水线
• 健康检查
• 告警
• 仪表盘
• 日志
• 回滚脚本
• 基础设施即代码
• 复盘报告

教训很简单：

如果流程重要，就把它编码进去。

不要指望有人在凌晨 2 点还记得它。

现在我们正在智能体上重复同样的错误。

我们把所有运营知识都塞进一个巨大的提示词，然后对智能体遗忘某些东西感到惊讶。

提示词不是操作手册

提示词可以描述应该发生什么。

操作手册控制可以发生什么。

这个区别很重要。

提示词说：

“在完成前运行测试。”

操作手册说：

step: run_tests
command: pytest
required: true
on_failure: stop_and_debug
success_condition: exit_code == 0

提示词说：

“小心处理生产数据。”

操作手册说：

permissions:
  read:
    - staging_db
  write:
    - none
  production:
    - denied

提示词说：

“创建一个好的 PR。”

操作手册说：

before_pr:
  - check_diff_size
  - run_linter
  - run_tests
  - verify_no_secrets
  - summarize_risk
  - request_human_review

一个是建议。

另一个是基础设施。

问题不在于智能体笨

问题在于我们一直在给智能体人类形态的指令，却要它们执行机器形态的工作流程。

人类可以从歧义中恢复，因为他们带来记忆、判断、恐惧、上下文和社会压力。

智能体不行。

它们需要那些软件系统一直需要的东西：

• 状态
• 约束
• 类型化输入
• 重试
• 检查点
• 日志
• 权限
• 测试
• 回滚
• 确定性控制流

没有这些，智能体可能仍然会产生令人印象深刻的结果。

但你无法运营它。

而如果你无法运营它，你就无法信任它。

“智能体循环“正在成为新的部署流水线

最重要的问题将不是：

哪个模型最好？

而是：

智能体允许做什么？我们如何验证它做对了？

这意味着每个严肃的智能体系统都需要回答基本的运营问题：

权限： 智能体可以调用哪些工具？ 它可以写文件吗？ 它可以访问生产环境吗？ 它可以发消息吗？ 它可以花钱吗？

状态： 智能体现在知道什么？ 它已经尝试过什么？ 步骤之间发生了什么变化？

验证： 哪些检查是强制的？ 哪些输出需要测试？ 哪些声明需要证据？

可观测性： 智能体读取了什么？ 它修改了什么？ 哪些工具调用失败了？ 它在哪里幻想成功了？

回滚：

我们能撤销这个更改吗？

我们能回滚 PR 吗？

我们能恢复之前的配置吗？

这些不是提示词工程问题。

这些是平台工程问题。

“直接让智能体验证“是不够的

这是我看到的最常见的失败模式。

人们让同一个模型做工作并验证工作。

这就像在没有检查指标的情况下问部署脚本生产是否健康。

答案可能是对的。

但它不是控制系统。

验证必须变得外部化和程序化。

示例：

• 测试必须真正运行
• 截图必须真正捕获
• API 响应必须真正检查
• 文件必须真正存在
• 差异必须真正检查
• 链接必须真正可解析
• 命令必须返回真实退出码
• 生成声明必须引用真实来源

如果智能体说“完成了“但没有系统验证它，工作就没有完成。

只是被自信地描述了。

未来的智能体技术栈看起来很无聊

这就是重点。

下一代有用的智能体基础设施将看起来不那么像魔法，而更像 DevOps。

它将拥有：

• 任务队列
• 工作者边界
• 工具注册表
• 内存作用域
• 审批门禁
• 日志
• 追踪
• 策略文件
• 评估
• CI 检查
• 回滚钩子

智能体不会是一个巨大的自主大脑。

它将是一个受控运行时中的工作者。

有时它写代码。

有时它审查代码。

有时它读取文档。

有时它打开浏览器。

有时它触发另一个工作者。

但周围的系统决定：

• 下一步是什么
• 哪些工具可用
• 什么算成功
• 失败时会发生什么
• 何时需要人工批准

可靠性来源于此。

不是来自在系统提示词中添加又一段话。

错误的抽象是“智能体即员工“

很多人把智能体描述得像员工。

给他们一个目标。 给他们工具。 让他们自己想办法。

这很有吸引力。

但也很危险。

更好的抽象是：

智能体即生产工作者

工作者有：

• 一份工作
• 一个队列
• 权限
• 输入
• 输出
• 日志
• 重试
• 失败状态
• 升级路径

你不会让工作者“小心“。

你约束环境，这样粗心就无法破坏系统。

这就是转变。

从：

请遵循这些指令

到：

以下是工作流。
以下是允许的工具。
以下是必需的检查。
以下是检查失败时会发生什么。

CLAUDE.md 不够

项目指令很有用。

技能很有用。

记忆很有用。

但它们本身还不够。

CLAUDE.md 文件可以告诉智能体项目如何运作。

它不能保证智能体遵循发布流程。

技能可以教智能体一个工作流。

它不能保证工作流正确执行。

记忆可以保留上下文。

它不能替代验证。

这些文件正在成为新的操作手册，但它们仍然需要一个运行时围绕它们。

一个真正的智能体系统需要两者：

1. 知识层： 文档、技能、记忆、约定
2. 控制层： 状态机、工具策略、检查、审批、回滚

大多数团队在第一个上过度投入。

它们在第二个上建设不足。

智能体平台是新的平台团队问题

这就是为什么 DevOps 和平台工程师应该关心。

智能体正在成为另一类生产参与者。

它们将触及：

• 代码仓库
• CI/CD
• 云账户
• 工单
• 仪表盘
• 事件
• 文档
• 客户数据
• 内部工具
• 部署工作流

如果你不会在没有护栏的情况下给初级工程师直接访问生产环境的权限，你也不应该给智能体。

而且如果智能体要在你的工程系统内运行，它需要与其他所有东西相同的平台原语：

• 身份
• 访问控制
• 审计日志
• 环境边界
• 策略
• 可重现性
• 恢复

智能体不是在取代平台。

智能体正在成为平台的客户端。

关注 @ghumare64 获取更多内容，并与那些大规模构建智能体的人分享这篇文章。