让 Agent 真正执行，而不只是建议

有一段时间，我用 AI 做了很多「起草」工作——起草邮件、起草 GitHub issue 描述、起草 Slack 消息。AI 给出结果，我复制粘贴，点发送。

这个流程用着还行，但有一天我意识到：AI 在帮我做的，只是输入法的升级版。生成文字的质量提高了，但「复制→粘贴→点发送」这条执行链，依然是我自己在跑。

这个认知让我开始认真思考一个问题：Agent 的「最后一英里」在哪里，为什么没有打通？

生成与执行之间的裂缝

大多数 Agent 流程是这样的：用户提需求 → AI 生成内容 → 用户手动去完成动作。

这条裂缝的存在有历史原因——早期 LLM 没有 Tool Use，只能生成文本。但 Tool Use 出来之后，很多人的使用习惯没有跟上。还停留在「让 AI 帮我写草稿，我自己去执行」的阶段。

这不是说草稿没价值——有些场景确实需要人工审核再发送。但把「人工审核」当成所有场景的默认值，是一种懒于设计的表现。

真正值得问的问题是：这个动作，有多少比例是我看一眼就会直接执行、不做任何修改的？ 如果超过 80%，那这条链路就值得自动化。

打通执行通道的工程模式

让 Agent 真正执行外部动作，有几个不同层次的实现路径：

最轻量：用 MCP（Model Context Protocol）挂接现有工具。支持 MCP 的宿主（如 Claude Code）可以直接调用 GitHub、Slack、Notion 等平台的工具，无需额外编程。适合个人工作流。

中等：用 Composio、Zapier 之类的工具路由层，通过统一 API 接入 1000+ 服务，省去每个平台单独接 OAuth 的繁琐。适合快速构建 Agent 集成，不想自己维护认证状态。

完整自持：自己实现 Tool 函数，精确控制每个动作的参数、错误处理、幂等保障。适合生产级工作流，要求对执行行为有完全的可观测性。

三条路径各有适用场景，不存在哪条「更好」。关键是意识到这条链路可以打通，然后按实际需求选择成本最低的方式。

执行型 Agent 的设计边界

打通执行通道不等于「让 Agent 随便执行任何东西」。我有几条自己的边界原则：

不可逆动作必须有明确确认。发 Slack 消息可以直接执行，但删除数据库记录、发布到公开平台、转账类操作，必须有人工确认节点，无论自动化程度多高。

执行必须可观测。每次 Agent 执行外部动作，要能查到：执行了什么、什么时间、结果是什么。不能是黑盒的「它说成功了就相信它」。

失败必须有补偿路径。外部 API 会失败、会超时、会返回意外错误。执行型 Agent 需要明确的重试策略和失败兜底，而不是「失败了就什么都没发生」。

这三条原则不是约束，而是让执行型 Agent 真正可信赖的前提。没有它们，打通执行通道反而会带来更多麻烦。

一句话心法

Agent 的价值不在于生成更好的草稿，而在于缩短从「决策」到「完成」的路径长度——识别出那些你每次都会直接执行的动作，把它们从你的操作队列里彻底移除。