北京
一个完全不懂编程的人，仅靠向Claude Code输入提示词，就搭出了一套能自动生成技术博客的流水线。预约系统、小游戏、菜单栏应用，他都是用同样的方式做出来的。这套流水线最初被设计成一个七代理系统：总代理协调，下设关键词选题、一手素材调研、提纲、撰稿、发布格式化，还有一个独立的质量评分员。直觉告诉我，把任务拆给不同“专家”，每个环节会更专注，产出质量也会更高。
可当作者把一篇跑完全程的文章拖进账单里拆解时，这套分工逻辑立刻站不住脚。那篇关于本地图像生成的操作文，正文约4000字符、带两张示意图，最终输出的文章主体只消耗了大约4000个令牌。而整个流水线的总令牌用量，是它的1738倍。逐项拆开，79%的计费令牌都花在了“缓存重读”上——系统提示、技能定义、角色说明，这些一模一样的共享上下文，每跨一个代理边界就被重新读取一遍。
问题出在一个看似理所当然的设计前提上：各个阶段是严格按顺序“一个接一个”执行的，没有并行辩论，也不存在交叉校验。拆成七个主体并没有改变同一个模型基于同一批源材料做判断的事实。角色拆分只额外制造了成本，却没有给判断质量带来任何增益。算下来，单篇文章的生产费用高达41.7美元。
于是作者做了个大胆的决定。他把七代理架构连根拔起（另一条姐妹流水线还用了九个代理，总共十一个子代理），将六个步骤——①选题→②抓取一手材料→③列提纲→④撰稿→⑤质量评分→⑥提交——整合进一个自顶向下逐步执行的单独会话里，只把QA环节保留为独立过程。同一篇文章在新旧两套设计下分别跑到底，比对结果让矛盾感扑面而来：总令牌用量上升了27.7%，而单篇成本却骤降87.7%。
多出来的令牌到底发生什么了？原来，合并后的单会话让模型能够一次性处理整段长上下文，不再频繁切换、不再重复注入同一套提示词。虽然总消耗量略微攀升，却甩掉了反复缓存读取带来的巨额计费负担。换句话说，当模型本身已经足够强悍时，过于精细的角色拆分非但不增效，反而成了最大的浪费。扔给模型一套完整的指令链，比拆成多个“专家”在中间来回递话要划算得多。
这个用实测数据硬碰硬推翻假设的案例，给当下热衷多代理框架的人敲了一记警钟：多代理不是万能招牌。在设计自动化流程时，真正要紧
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
