一条流水线八个 skill，真要八个 Agent 吗
Hello，我是飞飞。
你把调研、写稿、润色、评阅拆成不同岗位，是不是就该给每个岗位配一个 Agent？我这条写作流水线，正好能拿来对照。
八个专业 skill，不必对应八份独立上下文。需要换一套规则，主会话可以接着读。独立查错、并行研究或隔开大量一次性材料，才值得考虑另开上下文。
Anthropic 十月二十二日的新指南，面向企业 Agent 部署，讨论哪些子 Agent 可以收回主循环。我还没有做合并前后的耗时、token 对照。这次先核指南，再看自己哪些边界值得保留。
名字不同不代表分身
我这条链分成调研、写稿、润色、评阅、训练、配图、分发、发布八个专业 skill。发布按用户意图选择运行，其余按依赖接起来。
其中有 content-writer、content-polisher、content-reviewer。名字像三个岗位，可“岗位”只是把专业要求分清，不能直接说明它们如何运行。
skill 是一份可复用的做事说明。写稿读写作要求，润色读表达规则，同一个主会话可以接着做。稿件、原始资料和刚才为什么改那一句，都还在手边。
子 Agent 则另开一份上下文，带着自己的指令和工具去干活，再把结果交回来。Claude Code 文档也按这个区别建议：反复修改、多个阶段共享大量背景时，主会话往往更合适；输出很大、工作独立、需要限制工具时，再考虑子 Agent。
两种东西也能搭在一起。skill 文档允许用 context: fork 把一次 skill 任务放进独立子上下文。看见 SKILL.md，只能确认有规则文件，不能数成一次新 Agent 调用。
还有些步骤根本不必再请模型判一次。正文中文字符够不够、小标题有没有超长，仓库里已有脚本检查。把这些硬条件交给程序，能直接报出哪项不合格；再让一个“格式专家”把同一个数字读一遍，未必增加价值。
这与合并子 Agent 是两种改动。保留检查，把执行方式换成确定的工具；专业判断仍由模型做。我不会为了少一次调用，把必须通过的检查一起删掉。
所以，我这条流水线该数的，是实际开了多少次独立执行。不是目录里有多少个专业名字。
写稿改稿共用什么
拿我的文章说，调研找到的原文里，常有一句不能丢的限定。写稿要用，润色也得守住。
十七号那篇 DeepSeek 搜索接口稿，就得分清按请求计费和按文章数算钱。写得顺口了，也不能把“每千次成功且有结果的请求”揉成“每千篇文章”。
假如写稿交给一位，润色再交给另一位，后者只拿到一段“文章已核事实”的摘要，那句限定就可能没跟过去。这是对交接风险的分析，不是说那篇真的发生了漏传。
让主会话读完写作 skill，接着读润色 skill，能少一道把来龙去脉重新压成摘要的过程。专业标准照样分开，文章仍是同一份文件。
但共享上下文也有成本。原文、草稿、删掉的句子堆多了，后面每一步都要背着这些东西走。我不能因为少交接，就把所有旧材料一直留着。该落盘的落盘，关键限定留到交接记录里，仍然要做。
这也是我不打算把八份说明揉成一份巨大提示词的原因。需要哪段专业规则时再读哪段，和让模型每次从头吞一整本手册，负担不同。
那次空转怪谁
七月十九日的旧文，记过一轮批量出稿。十篇稿子排进去，我想着让它们自己跑。回来看，八篇撞到三轮重改上限，仍在等我拍板。
它们没有停着不干。整个批次已经跑了约六十四次 Agent 调用、烧掉两百七十万 token。调用在涨，交付却没出来。
看着这笔旧账，很容易顺口接一句“Agent 太多，果然浪费”。可旧记录支撑不了这个因果。
那时的规矩是低于八十分就打回，最多三轮，仍不达标就停。每轮评阅重新看全文，修改又没用对专业方法。它可以一遍遍提出意见，却没有把稿子推到能交的状态。
后来改的是循环规则：只做一轮定点重改，改完如实报分，主观评分默认不再把整条流水线锁住。现有 reviewer skill 仍留着这段复盘。
这证明我曾经把停止条件和改稿方式设计坏了。可换成一个 Agent，同一批稿子就能更快更好了吗？旧账回答不了。后者需要同材料、同验收条件的对照，旧文里没有。
我更想问的是，每次调用带回了什么。如果只是一张和上一轮很像的意见单，再多开一位评审，也救不了没人落实的修改。
另一双眼睛留着
有一道边界，我仍会保留：独立评阅。
写完再给自己打分，容易沿着刚才的写法解释“这句为什么合理”。另起一个没参与改稿的上下文，只给成稿、证据和评分标准，至少能让它从不同起点挑错。
我这套 reviewer 的要求就是 fresh subagent。主观分数仍会有波动，所以边界分还会追加独立评阅。独立上下文提供的是一次重新审视的机会，不保证它一定客观，更不保证多叫一个就多发现一个错。
另一类值得隔开的，是会塞进大量一次性输出的研究。四月那篇省 token 旧文里，我写过把目录探索交给子 Agent，只让摘要回来。这个方向与今天的建议并不冲突。
关键在回来以后做什么。涉及文章主结论，摘要给了网址和判断，我还得回原文看。把一大堆搜索过程留在外面，可以减负；把支撑结论的限定也一起扔掉，就省错了地方。
所以保留子 Agent 的理由，得落在独立验证、可并行的独立工作、工具权限或上下文负担上。“它听起来像个专家”，还不够。
先查执行记录
你可以先拿一篇完整稿子的执行记录看：写作和润色是否各开了新上下文？后者是否又重读同一份原文、草稿和规则？
两项都中，就值得列为合并候选。若本来就是主会话按顺序读两个 skill，就没有两位执行者可合，别为了追新建议再改一遍。
放到我这条链，眼下能分清的是这些边界：
| 环节 | 为什么这样分 |
|---|---|
| 写稿接润色 | 连着用同稿和事实限定，值得检查是否有重复交接 |
| 字数和标题检查 | 规则明确，脚本能报具体不合格项 |
| 独立评阅 | 要另一份上下文重新挑错，保留独立执行的理由 |
| 大量搜索与探索 | 看输出量和独立性决定，不能只因叫调研就拆开 |
这张表不是合并完成的成绩单。它给每一条边界一个可核的理由。写稿接润色列成候选，也不等于马上把检查删掉。
真正动手前，还得给候选留一份对照。原始材料、规则版本、要交的文件和外部评阅标准固定，只改变这一段怎样执行。
记录整段耗时，主会话和子任务的用量一起计，再逐篇看哪些规则漏了、哪些地方多改了一轮。不能拆开时用独立评阅，合并后只听主会话说“不错”，再把分数相近当成质量没变。
官方指南恰好给了一个反例：示例客服 Agent 合并后延迟低了，却绕过配送专家，没取配送日期就回答。原来能过的流程，反而坏了。
这条比“少一次调用”更值得记。同一份材料也要多跑，逐项看原先能守住的规则有没有丢，不只看平均分。变快了，却漏掉必须完成的一步，这段就先别合。
对照还没做，流水线配置也没在这篇里动。我眼下能做的，是给每一次另开上下文写出理由：它带回独立问题，挡住一大堆一次性材料，还是只把同一段话再转一次？
八个专业名字可以留下。执行记录里多出来的每一次等待，得能对应上一件值得它花的事。