跑了几百个 Agent 会话后，我留下了三条系统规则

九月上旬某天，我让自建的 DeepSeek harness（下称 DSH）跑一轮竞品信息扫描，几十个子代理正在各自抓资料，其中一个突然发现内置搜索工具开始返回 HTTP 402——配额用完了。它没有停下来等我，自己翻了一遍工作区里的旧脚本，找到两条不花钱的检索路径，接着把自己那部分任务跑完了。

先交代两句背景。DSH 是一套常驻后台的研究流水线，模型是 deepseek-v4.1-flash，主力用法是扇出：一个主代理把研究任务拆开，派出带角色设定的子代理并行干活；每场会话落成逐事件记录的日志，谁干了什么、调了哪个工具、失败在哪一步，事后都能对账。从 8 月中旬跑到现在，会话目录 336 个。这几百个会话里，配额耗尽、评审幻觉、449 封空邮件事故都撞过一遍，最后留下三条规则。它们不绑定 DeepSeek，换成任何自建 agent 系统照样成立。

规则一：能并行，但任务必须窄

我从会话记录里按天分组数过子代理数：9 月 8 日单日 108 个，9 月 24 日 71 个，9 月 19 日 53 个。命名能看出分工——demand-validation researcher（需求验证研究员）、primary-source documentation researcher（一手信源研究员）。一轮竞品扫描拆下来，一个分身只管一家公司在一个信源上的公开记录，查完交结构化字段走人。任务窄还带来一个副产品：失败变便宜。一个分身查砸了，重跑一次就是一次 API 调用，不需要人去现场收拾，也不污染其他分身的产出。

什么时候值得开到三位数？我的判断标准是三条同时成立：任务能干净地切成互不依赖的窄问题（一家公司一个信源一种角色）；单个子任务失败无所谓，重来成本接近零；结果可以机械合并，主代理只做汇总。三条标准对应三种成本：切割成本、重试成本、合并成本，哪种付不起，扇出就卡在哪一关。三条里有任何一条不成立，扇出就是在放大混乱：任务边界没切干净时，多个分身会对同一对象做重叠检索，合并阶段的冲突字段要人工裁决，这种时候少开几个反而快。扇出的经济账不在分身数量，在每个分身的任务窄到不需要再判断。

可带走的做法：先切任务，再谈并行。把每个子任务切到执行者不需要判断的程度——对象固定、信源固定、产出字段固定；切不动的任务留给单个会话慢慢做，开一百个分身救不了它。

规则二：能失败，但必须降级

回到开头那个 402。内置 web_search 是配额制的，大规模扫描时耗尽是常态。子代理的自救路径是工作区 .research/ 目录里的两个脚本：esearch.sh 调东方财富的搜索 API，解析出日期、标题、媒体名、链接和摘要；brss.sh 请求 Bing 的 RSS 接口，解析出标题、链接和描述。信源质量比全量网页搜索差一截，但不要配额，金融资讯和中文网页各占一头，输出格式贴着子代理的需求走，不浪费本就吃紧的上下文窗口。

我在这条路径上加了一条硬纪律：凡是用降级检索拿到的材料，产出的报告必须带一段”检索受限声明”，写明用了哪条降级路径、覆盖面缺了什么。降级检索撑起的结论可信度打了折扣，读报告的人（经常是隔了一周的我）有权知道这个折扣。诚实标注的成本是一段话，不标的成本是把局部信源当成全量证据。

这条规则只管一类问题：外部依赖没了，任务还能不能继续。系统早期能靠子代理自己翻旧脚本活下来，是运气；402 那次走通，靠的是工作区里恰好躺着两个旧脚本，把”恰好”变成”必然”，才是这条规则要干的事。但不是所有失败都是依赖失败——有一类事故里工具全是好的，坏的是动作本身没有门禁，那是规则三的事。

可带走的做法：给每类任务预设降级路径（主工具挂了走哪条备用链路、降级材料怎么标注折扣）。系统的生存力不在正常路径跑得多顺，在降级路径是否事先存在。

规则三：判断和动作，都需要确定性门禁

DSH 的另一条流水线是三段式：ChatGPT 出方案，DeepSeek 落地，ChatGPT 复审。第三段我定了一条协议——评审意见必须先机械核验再执行。

出处是 2026-08-16 的实测记录。sample2 任务连续两轮评审都报告”徽章 Markdown 语法损坏”，机械核验给出 4/4：徽章格式全部匹配标准式样，括号配对平衡，评审声称的损坏模式在产物中出现 0 次。判定误报，驳回，产物不动。同一批测试里，sample1 的第一轮评审抓到一个真 bug——摘要生成器跳过了子目录文件，导致摘要缺源码，修复后第二轮评审通过。

同一个评审模型，既能抓到真 bug，也会制造根本不存在的问题。把评审意见当指令照单全收，你会为幻觉改代码；全当耳旁风，你会漏掉真 bug。可靠的分界线是机械核验：评审说坏了，就用正则、测试、实跑去验证它说的那个坏法存不存在，存在则按优先级修，不存在则记档驳回。

判断侧的教训来自评审幻觉，动作侧的教训来自 449 封空邮件。8 月 22 日，一个子代理执行对外项目的发信任务，发出 449 封空正文邮件。事后看，这不是降级失败：SMTP 通道是好的，发信动作也”成功”了，坏在没有一道门禁拦住”正文是空的，为什么还发”。之后两天的会话记录全是事故恢复：SMTP 通道逐封验证 323/323，次日按分级补发（致歉 3 封、说明 10 封、正文重发 310 封），随后给发信类任务加上正文非空校验和证据台账。这类事故和评审幻觉同源：agent 的自述会错，agent 的动作也会错，而动作一旦对外，错误直接落进别人的收件箱。降级救的是工具没了，救不了动作没设防。

所以门禁要同构地铺到每一类判断和动作上。我固定跑四道：评审意见进执行队列前过机械核验（正则、测试、实跑）；发邮件进发送队列前过 preflight（正文非空、收件人数在预期内、预览留档）；数据写入前过 schema 校验，字段不齐拒写；对外动作一律先 dry-run 再真做。四道的共同点是用确定性代码把关，不是再派一个 agent 去看一眼。核验本身不贵，一段正则加一次测试跑；贵的是没有门禁的版本——为幻觉改一次代码，漏一个真 bug 上线，或者给 449 个人发一封空邮件。

可带走的做法：判断和动作都先进门禁队列，再进执行队列。门禁写成能自动跑的检查（正则、测试、diff 对比、schema 校验、preflight），别靠人眼对——人眼对一遍，等于又引入一个会出错的评审员。

边界

三条规则管住并行、降级、判断与动作三类风险，管不住”该研究什么”。1M 上下文窗口听着大，一场跨两周的研究里真正难的是判断的连续性，这件事目前还是我自己做。降级路径解决了配额的生存问题，确定性门禁解决了评审与动作的可信问题，但选题这件事，机器还没有替我回答过。这也是我把三条规则写在系统层的原因——模型半年一换，系统的骨架会用很多年。运维层也交过学费（macOS 权限锁死日志，服务以退出码 78 反复拉起失败，数据迁出 ~/Documents 后根除），但那是一次性的坑，修完就没了，不配进规则。

这三条规则都是系统层的：换掉 DeepSeek 照样成立。只换模型不立规则，配额、幻觉、空邮件的账单还会再来。