一个对比三个城市的人口、时区和一句话摘要的Agent，能有多复杂？Data4Sci博主Bruno Gonçalves偏偏挑了这么一个"简单到近乎荒谬"的任务，写了一篇教你把裸模型循环升级成生产级系统的教程。
理由很实际：三个城市自然拆成九个可以并行的查询，最后的汇总报告又必须等九个都完成——这已经不是一条直线能走完的活。他还顺手给工具标了成本档位，人口和时区查询几乎免费（cost_hint=0.1），逐城摘要要调一次LLM（1.0），最后的汇总调用最贵（2.0）。一个玩具任务，把并行调度、结果验证和成本压力全凑齐了。
六个坑，六个补丁
裸模型循环——一个提示词负责规划、执行、总结、自我批评——在生产环境里会用几种很固定的方式翻车：
- 模型编造工具参数，因为它从没见过正式的参数schema
- 步骤只能一个接一个跑，九个独立查询也得排队
- 上下文窗口被塞满历史记录，模型判断力被稀释
- 某一步输出错了，没人拦，错误一路传到最终报告
- 一个提示词同时管规划和写作，风格和约束互相打架
- 没有预算上限，调用次数一多，成本说不清花在哪
对应的补丁也很直接：Pydantic驱动的类型化工具、把执行计划画成有向无环图（DAG）、分层记忆配检索预算、先便宜后昂贵的验证层级、拆出Planner/Worker/Critic三个角色、加一套多维度的预算监控。原文详细讲清楚了前面两块，后面几块——DAG具体怎么并行跑起来、预算怎么触发降级、每一步怎么被记录下来——需要往下多补一层。
计划变成图，执行才能并行
Planner不再一次只吐一个动作，而是把整张计划图一次性生成出来。三城市任务对应十个节点：九个互不依赖的查询，加一个依赖全部九个的汇总节点。
这套设计有个不显眼但重要的约束：Worker本身不含判断逻辑，它只执行、不评价。判断的活全交给独立的Critic，理由很朴素——写报告的人不应该给自己的作业打分。
预算这块的机制也值得单独说一下。系统同时追踪四个维度：token消耗、工具调用次数、耗时、预估成本，取其中利用率最高的一项作为压力信号，触发降级或终止。哪个维度先顶到红线，系统就先在那个维度上收手，而不是等某一个指标彻底爆掉才反应。每一步Planner、Worker、Critic的操作，还会被记成一条扁平的追踪事件，带上延迟、成本、压力值和判定结果，理论上可以完整回放整条执行链路。
计划先摆上桌，账本随时能翻，这是这份教程真正硬的地方。
类比讲得响，证据没跟上
文章开篇拿空战指挥体系做类比：任务规划者对应Planner，并行编队对应并发Worker，油量红线对应预算，飞行记录对应Tracer，战后复盘对应Critic。类比很顺，但作者接着把Claude Code、Devin、Cursor、Hermes这几款产品也拉进来，说它们"采用了完全相同的分层结构"。
这句话没有一手证据支撑。这几款产品各自的内部架构没有公开到能验证"完全相同"的程度，更像是用一个自洽的框架去反推别人应该怎么做，而不是拿到了对方的设计文档。类比可以帮读者理解结构，但不能替代验证——这一步文章自己没有说清楚,读者信不信,得自己留一道保险。
更值得留意的是这套教程系列自身的进度。文中反复提到"未来的04号notebook"会把worker池拆得更细、补上eval suite和检索benchmark，但检索显示，公开仓库里目前只有01到03号，04号一直没有上线。一篇讲"让每次任务可复盘、可验证"的教程，自己却处在一个没交代清楚的未完成状态——这不是致命问题，但和它标榜的严谨劲儿,多少有点错位。
- 提醒.文中的六个原语代码可直接抄进真实项目当模板，但"这套架构等同于生产级产品内部实现"这个类比，目前只是修辞,不是事实。
对正在自建Agent系统的团队来说，这篇教程的价值是实打实的：类型化工具、DAG调度、分层记忆、预算压力信号，这几块拿来当起点没问题。但如果指望它证明了"Claude Code也是这么干的"，或者指望这套东西已经在真实生产环境里跑通了压力测试——那份证据，教程里没有，04号notebook什么时候补上，才是接下来真正该盯的地方。