开发者谈构建AI Agent：从复杂框架回归简单提示

毕加索有句名言常被引用： “我花了四年时间画得像拉斐尔，却用了一辈子才画得像个孩子。” 他的作品《公牛》（Le Taureau）完美地体现了这一点。经过 11 次迭代，毕加索逐步剥离公牛的细节，直到只剩下寥寥几根线条。然而那头公牛依然一目了然。 在学习构建 AI agent 的过程中，我深有同感。一切又回到了原点。 和许多工程师一样，我从抽象和复杂的软件系统入手。框架、编排引擎、多 agent 架构、状态机、向量数据库、记忆系统，以及精心设计的规划机制。 在这段旅程中，我迷失了方向。我把技术摆在了问题前面。我的自尊心在作祟。我试图在 AI 时代作为一名工程师保持自己的相关性。 我混淆了运行 agent 所需的基础设施与构建一个有用 agent 真正需要的东西。 我实验得越多，就越发现自己在一层层地剥离。 模型在变得更好。越来越多的事情只需一个 prompt 就能搞定。但这并不是全部。是我一直把事情搞复杂了。 创建一个 agent 所需要的，不过是一个装着 Markdown 文件的文件夹。 指令、上下文和可复用的 skill。对工具的访问权限。一种调用 agent、验证结果并纳入反馈的方式。这些大部分只需要和 Claude 聊天就能搭建起来。 mkdir my_awesome_agent cd my_awesome_agent claude 然后开始一段对话。 “Claude，我想构建一个能做 XYZ 的 agent。帮我初始化它。创建一个 AGENTS.md，然后我们一起弄清楚它还需要什么。” 这里有一个重要的区别。Claude 本身就是一个 agent，具体来说是一个 coding agent。有人用 harness 这个词。我是在用一个通用 coding agent 来创建一个专用 agent。为清楚起见，Claude 可以是任何 coding agent：Gemini、Codex 或 pi。更重要的是指令和上下文。 我不是从零开始构建智能。我是在定义现有的智能应该如何完成某项特定工作。 我和 Claude 一起梳理几个问题。 实际的工作是什么？不是该用什么框架，除非你要创建一个框架。成功是什么样子的？agent 可以独立做出哪些决定？哪些事情它在没有许可的情况下绝对不应该做？ Skill 是可以复用和重新组合的专门指令。互联网上有大量优秀的示例。借用它们、改造它们、组合它们，或者让 Claude 创建新的。 通常，一个 skill 只是一个包含指令的 Markdown 文件，或许再加上一些辅助资源。 agent 需要上下文：你的业务是做什么的、你的客户是谁、你的代码库如何运作，或者某些领域特定的知识。这些都可以作为 Markdown 文件放在文件夹里。有些上下文可以在需要时检索。有些来自对话本身。你并不自动需要一个向量数据库或复杂的记忆架构。 要完成一项工作，agent 需要工具。也许它需要搜索网页、读取数据库、调用 API、执行脚本，或者与浏览器交互。 引入一个工具就像启用一个插件或添加一个 MCP 连接器一样简单。 我让 Claude 帮助确定完成任务所需的最小工具集。工具甚至可以动态创建，由 agent 编写并调用代码。agent 还可以在互联网上找到工具并安装它们。 要让 agent 有用，它需要作为工作流的一部分被调用，无论是通过 cron job、webhook 事件，还是另一个程序。 简洁之处在于打包方式。一个装着指令的文件夹就是一个干净的可部署单元。它可以被版本化、到处复制，并嵌入到其他流程中。 有了 Claude 以及所需的工具和凭证，就可以使用 -p 标志以 headless 方式调用它： cd my_awesome_agent claude -p "Do awesome stuff" Headless 意味着没有交互式聊天。Claude 接收任务，在 agent 的文件夹中工作，打印结果，然后退出。脚本可以传入任务并收集输出。对于无人值守的工作，我会提前配置好工具权限。Claude 还可以返回结构化的 JSON 供另一个程序使用。 Anthropic 关于 headless 执行的文档涵盖了相关命令和配置。 当 agent 启动时，它需要知道去哪里找自己的指令、收到了什么输入，以及是否应该继续之前的工作。调用机制可以改变，而 agent 的根本目的不变。 这套设置可以部署在远程 VM 上，用钩子触发 agent，并通过隧道提供对调用它的服务的访问。 这个 agent 也可以在沙箱中部署和调用。我在 Fife 中探索了这一点，那是我基于 Modal Sandboxes 构建的软件 agent 工厂。 Fife 接收 GitHub issue，为每个任务在隔离的沙箱中运行一个 coding agent，并返回经过测试的 pull request 供人工审查。多个 issue 可以并行处理，每个都在自己的环境中。由人来审查结果并决定合并哪些。 这正是情况大幅改善的地方。我现在只需一个 prompt 就能完成任务，无需繁琐的指令。如今，我常常只是信任它自己去把活干完。而且我期待它会越来越好。 当它出错时，我会和 Claude 一起复盘。发生了什么？缺少了什么？我们应该改变什么？ Claude 将本地会话记录保存在 ~/.claude/projects/<project>/<session>.jsonl 下。每份记录都记下了对话、工具调用和工具结果。它提供了任务如何展开的轨迹：Claude 被要求做什么、它尝试了什么、工具返回了什么，以及错误出现在哪里。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）