（注：本文为小报童精选文章。已订阅小报童或加入知识星球「玉树芝兰」用户请勿重复付费）

授人以鱼，不如授人以渔。

引子

9 月末的组会上，我给研究生演示了目前我用 Claude Code^[1] 搭建资料调研整合系统的实践成果，尤其详细展示了「跑完一次」后生成博客的完整项目文件夹 —— 中间多个过程文件把整个流程、Agent 交互记录得很完整详细。因为用了独白形式，表现也很有趣。

我把这次组会演示的录像放到了 B 站^[2] 上面，做成了一个充电视频。

演示阶段的前大半内容你都可免费观看。在后半段，我介绍了几个用到的 Agent 各自的定义方式。

这一部分当然是设计一个 Agentic AI 系统的关键。Agentic AI 系统不同于传统的工作流，我们实际上是让不同的大模型承担不同的角色与任务，并相互配合，完成复杂的任务乃至完整项目。

在以前，这样的工作，你需要先熟练掌握 CrewAI 或者 Agno 这样的框架，才能慢慢搭建。但是现在，有了 Claude Code ，使用门槛大幅降低。看着 AI 的表现，学生们很兴奋。

演示过程中我问研究生们有什么疑问。一年级的学生们表示没有问题，因为看着眼花缭乱，信息过载，啥也问不出来。二年级的学生许隆鑫因为跟着我在做项目，所以很敏锐地问我：「老师，每个 Agent 的提示词是您手写的吗？要是手写，恐怕很难写得如此完整清晰。」

我当时对他的这个问题大加赞赏，号召大家「见贤思齐」。因为这个问题，证明了隆鑫同学确实是对 AI 熟悉了，有过经验、踩过坑，才能够一眼看出来这里的门道 —— 要纯人工手写这样复杂的提示词，是非常困难的。

我明确告诉他，这种系统级配置很难靠手写完成 —— 要做到既全面又细致，几乎不现实。尤其是「为师我是个懒人」。如果要这么做的话，对我来说那简直就是折磨。

况且，我们前面强调过，这是一个相对复杂的多 Agent 协作系统。这就意味着你不仅要对一个 AI Agent 本身的行为描述清楚，还涉及各 Agent 之间的交接协议与接口定义等。

修改某个 Agent 的职责 / 约束时，会牵动其他 Agent 的行为和任务目标等要素定义。因此你在改一处时，必须要考虑整个系统当中若干处与它对应的地方都要因应调整。单是想想，我都觉得麻烦。

所以我实际上是用 AI 来做的这个事情。今天我就来给你讲讲我是如何用 Agentic AI 应用设计和迭代 Agentic AI 系统。我会分享所用的工具，常见陷阱，以及我经过不断实践，总结的一些高效提示词和工作流程。

工具

现在主流的 Agentic AI 工具有多种选项，其中下面这几个我实际深度测试和使用过。

• Claude Code^[3]

• OpenAI Codex CLI^[4]

• Google Gemini CLI^[5]
  

  本质上，这些框架都默认对接自家大模型，例如 Codex CLI 使用 GPT-5 或者 GPT-5 Codex。也有部分框架支持替换其他模型，例如  Claude Code 可以用智谱清言的模型，但效果依适配程度而异。

用非 Agentic AI 原生模型的解决方案，往往都有一个共同点 —— 价格相对友好，适合高频批量使用。例如上图是 GLM + Claude Code 的方案。一个月高频使用，也只需要 100 元人民币。相对而言，要想用同样 token 数量的 Claude 模型，花费至少也要高上好几倍。

但是我必须提示你的是，每一个 Agentic AI 框架实际上都是和自己的模型交互打磨，然后对自家任务场景进行了各种各样的强化和修补。所以当你把某家框架强行接入其他家模型，需要提前评估潜在的「水土不服」，甚至是严重的「排异反应」。

一般而言，我使用 Agentic AI 框架时还是愿意使用它配套的原生模型，这样比较妥帖。

Gemini 3.0 据说马上就会出来^[6]，而且最近还推出了 Extension （我还没来得及测试），不知道能否让 Gemini CLI 的使用体验再上一个台阶。但是从目前来看，经过多轮测试我觉得 Agentic AI 领域领头羊还是 Claude Code 和 Codex CLI 。两者各有千秋，实际可用性都不错。

其中 Claude Code 的优点非常明显：它支持自定义的指令，可以设立很多子 Agent。外部支持的 MCP^[7]（Model Context Protocol）比较广泛 —— 毕竟 MCP 这个东西是 Anthropic 自己提出来的，因此接入与扩展更顺手一些。

Claude Code 生态系统好还体现在主流 AI 编辑器基本都能用 Anthropic 自家的插件来对接。例如 Visual Studio Code 上 Anthropic 的 Claude Code 插件免费，还能把主窗口作为 Claude Code 的工作界面，过程与历史记录清晰可查。

前一段，Claude Code 还有很多机会让你以更便宜的方式跟别人「拼车」来使用。许许多多的人都在想着各种办法薅 Anthropic 的羊毛。Claude Code 用量「榜一大哥」—— 咱们之前在星球也推荐过那期播客（见下文）—— 一位开发者一个人一个月可以用掉 5 万美元的 token ，而他其实只交 200 美元。不过这种失衡长期看来不可持续，平台自然会收紧策略，并且已经初现端倪。

个把月前，我使用 Claude Code 时还会比较纠结。最大的问题在于彼时它有两种模型可供选择：一个是 Sonnet 4，一个是 Opus 4.1。在当时我测试的结果发现，在规划环节，Opus 相对 Sonnet 优势明显。但是 Opus 是真贵啊。

因此那个时候常见做法是用 Opus Plan Mode 负责思考与分解，用 Sonnet 执行落地。不过「一分钱一分货」，我总会因为自己无法全程使用最顶尖的模型感觉遗憾。

直到 2025 年 9 月末， Sonnet 4.5^[8] 出来了，这基本解决了上述取舍的矛盾。Sonnet 4.5 的定价是和原来的 Sonnet 4 差异不大，但是能力显著提升，在多项指标上甚至超过 Opus 4.1。

对于官方发布的这种表格，我觉得你可以作为参考，但千万不要把它当成是绝对的事实。毕竟每个公司新品发布时总有一些营销的成分。

但令人欣喜的是， 我几天试用下来，感觉 Sonnet 4.5 模型确实是足够聪明。是不是在多项指标比 Opus 聪明不好说，但若以约五分之一的价格获得近似能力，性价比就很可观。所以我用起来非常开心。

这时候，你自然而然的想法可能是：既然手上已经有 Claude Code 账户且付费，设计出来的 Agentic AI 项目又在 Claude Code 运行，那干脆就直接用 Claude Code 去「自我修复或迭代」Claude Code 项目，不是顺理成章吗？

我的选择不是这样。

因为我觉得 Claude Code 有很多优点不假，但也有非常明显的问题 —— 就是它在跨文件、跨模块联动修改时容易遗漏。

Claude Code 往往会专注于其中的某一个部分给你改下去，但随时可能忽略对项目整体进行全盘的考虑。我说这话是有依据的，因为我不止一次在对话里提醒它：「难道就只修改这几个文件吗？」然后 Claude Code 思考后跟我认错，并且真的去继续修改其他相关联文件了。这态度是不错，可搞得我非常无语，每次用的时候，心里都没底。