多 Agent 协作的真实成本
我把最近几份调研——多 Agent 协作模式、自主循环机制、AI 用量监控——拢到一块儿整理了。三个看着各不相干的题目，做完才发现它们指向同一个问题：个人开发者搞多 Agent 系统，怎么才能不把自己搞破产？
真的需要那么多 Agent 吗
学术界把多 Agent 协作切成合作、竞争、合竞三类，通信结构分集中式、去中心化、层级式，协调策略又分规则驱动、角色驱动、模型驱动。这套分类学画得挺漂亮，但落到个人场景，大多数时候你只用得上两种拓扑（topology，就是”几个 agent 之间怎么连线、谁跟谁说话”的结构）。
星型（Star）——一个调度者把任务派给几个执行者，再把结果收回来汇总。比如代码审查：一个主 agent 把 PR 甩给三个子 agent，分头查规范合规、扫 Bug、看架构影响，最后把报告并到一块。Maple 的 cardo-pr-review 就这么干的，跑了好几个月，稳。
流水线（Pipeline）——串行的流水线，上一步的产出就是下一步的输入。最典型的场景是：写完代码，交给一个独立的 Tester 去挑刺。这里的关键词是”独立”——同一个 agent 又写代码又写测试，测试会顺着它自己写代码时的思维盲点走，等于让作案的人去查自己的案，查不出来。所以 Tester 必须是独立的 AgentRun，只拿代码成品和需求规格，拿不到 Developer 当初是怎么想的。
这两种拓扑，把 Maple 日常 90% 的多 Agent 需求都盖住了。
那网状（Mesh）呢？就是一堆 Agent 互相通信、辩论、投票，吵出一个共识。学术上确实好看——MIT 和 Google 的研究说，多 Agent 辩论能把事实准确率拉高 23%，异构多 Agent 辩论甚至能把人物传记的事实核查从 60% 干到 80.6%。但网状拓扑烧的 token 大约是星型的五倍。个人场景里又没有多方利益要博弈，花五倍的钱去养一套复杂辩论系统，不划算。
行业数据也站这个判断：70% 的场景里，单 Agent 配一条调好的提示词，效果跟多 Agent 打平，成本只要三分之一。多 Agent 系统平均多烧 3 到 5 倍 token，出了故障平均要多花 3.7 倍时间才缓得过来。贵且脆，双输。
多模型交叉：最便宜的核验手段
网状辩论太贵，那有没有便宜的替代？有——多模型交叉审查。
思路特简单：同一份代码或文档，分别丢给 Claude 和 GPT 各审一遍。两个模型都点出来的问题，可信度能涨 25% 到 35%。这本质上就是一个星型拓扑加上多模型路由，不用让 Agent 之间互相通信，也不用搞那套复杂的网状编排。
为啥这招比网状辩论实用？因为不同模型有不同的系统性偏差（systematic bias，就是这个模型天生爱往某个方向想、习惯性忽略另一些角度）。Claude 偏爱某些分析视角，GPT 偏爱另一些。让它俩当面”辩论”，成本是 5 倍；让它俩各审各的、最后人工合一下，成本大约 1.5 倍——效果差不多，钱差一大截。
这里头还藏着一条”让大模型当裁判”（LLM-as-Judge）的实用规矩：别用 Claude 去评 Claude 自己写的东西，自己夸自己，分数虚高。至少上两个不同厂商（provider）的模型，再配一套结构化的打分标准，比开放式地问一句”这东西好不好”靠谱得多。自己考自己，没有不及格的。
Ralph Loop：一个跨 session 触发的”bug”
协作说完，说自主循环。
Ralph Loop 是 CC CLI 的一个插件，机制设计得很巧：用 Stop hook（退出钩子，就是”程序要退出时先回头执行一段你指定的脚本”）拦住 session 退出，检查任务干完没,没干完就把同一条提示词再塞回去，让 Claude 接着干。整个循环就靠三个文件撑着——一个启动脚本、一个 Stop hook 脚本、一个状态文件。
Maple 还自己写了一个 autonomous-hook，干的事不太一样：它不是把同一个任务翻来覆去做，而是从任务队列里一个接一个消费不同任务。两者都靠 Stop hook 来转圈，各自用 session_id 做隔离。
问题就出在这：Stop hook 是项目级的配置，可 session 是 CC 实例级的。同一个项目目录底下所有的 CC session，共用同一套 hook。一个目录配的钩子，目录里每个 session 都会触发。
我翻了 autonomous-loop.log 的 907 行运行数据：总共 449 次 Stop hook 触发，其中因为 session 对不上（mismatch）被拦掉的有 338 次——占了总触发的 75.3%。一个叫 41d7faac 的 session，在 autonomous-loop 跑的那段时间里，刷出 200 多条 mismatch 日志。另一个 session 92e221d8，两小时内刷了 100 多条，间隔大约 10 秒一次，明摆着是某个自动化工具在那儿不停触发。
这不是 bug。session 绑定机制干得没毛病——对不上的时候都是 exit 0 正常放行的。但每触发一次，照样得起一个 python3 进程、读一遍 flag 文件、写一行日志。75% 的触发全是白干，纯粹在烧资源。
这是个架构层面的天生限制：拿项目级的 hook 去过滤实例级的 session，注定会有一大堆无效触发。除非哪天 CC CLI 在 hook 匹配器（matcher）那一层支持按 session 过滤，否则光在 hook 机制内部，这问题解不了——病根不在你写的脚本里，在机制本身。
Vyane Scheduler：根本性的解法
Vyane 的调度器（Scheduler，见 ADR-006）已经把完整的替代路径搭好了。M1 到 M8 这一串里程碑全部做完，包括 SchedulerGate 这个三档灰度开关，和 TaskBoardBridge 这个盯文件变动的桥。
三档怎么切，很清楚：off 档下 autonomous-hook 照常注入、调度器不启动；shadow（影子）档下两者并行跑，调度器在旁边默默算路由、写对比日志，但不真接管——相当于先让它在副驾观察，不让它握方向盘;on 档下 autonomous-hook 直接早退（early-return，啥也不干就返回），调度器全面接管。
为啥说这才是治本？因为调度器是后台程序进程直接去调子进程（subprocess），压根不走 Stop hook。从架构上就把”同项目所有 session 共用一套 hook”这个根儿给铲了。每个 AgentRun 是一个独立的子进程，天生就是隔离的，用不着 session_id 匹配那种打补丁式的方案。把病根挖了，自然不用再贴膏药。
不过有一点得留着：Ralph Loop 那种”在同一个 session 里循环”的本事，是有它独到价值的。调度器每次都起一个新子进程，上下文丢了；Ralph Loop 在同一个 session 里转圈，Claude 能靠文件系统和 git 历史回想起自己上一轮干过啥。以后要真碰上那种必须在 session 内多轮迭代、还得守着上下文的任务，Ralph Loop 照样有它的用武之地——但那时候它该作为调度链路里的一个执行选项被调起来，而不是自己单蹦着跑。好工具不丢，只是给它换个正确的位置。
成本追踪：自建，不部署外部平台
我把 LiteLLM、Helicone、Langfuse 这一圈工具调研了个遍，结论是：个人开发者用不着它们。
LiteLLM 要配 PostgreSQL，Langfuse 更狠——PostgreSQL 加 ClickHouse 加 Redis 加 S3。光是伺候这套基础设施花的运维功夫，就远超它们帮你省下的那点追踪成本。更要命的是，Maple 主力的 AI 用法是 Claude Code CLI 的 Max 订阅，根本不走自建的代理（proxy）。而这些工具的核心前提就是”所有 API 调用都从我这个代理过一遍”——这前提从第一步就不成立，后面全白搭。
我推荐的方案是 SQLite 三张表：api_calls 记每一次单独的调用，daily_summary 做每天的汇总，model_pricing 存一张定价表。采集这头三条线并行——定时去拉 Anthropic 和 OpenAI 的用量（Usage）API；在每次 API 调用时，顺手从返回结果的 usage 字段里把 token 数当场抠出来；再用 ccusage 这个工具解析 Claude Code 在本地留的日志。
最顺手的接入点，是 Vyane 后台程序的 ai-gateway（AI 网关）层。这层本来就统一管着所有厂商的 API 调用，只要在它的响应处理链上挂一个用量提取钩子，把各家格式各异的 usage 字段统一抠出来、统一写进 SQLite——这比另起一套独立监控系统优雅太多。每次调用自动入账，不用额外的定时任务（cron job），不用外部服务，更不用伺候 PostgreSQL。在已有的路上加一道工序，永远比新修一条路省事。
预算告警顺着就来了：budgets 表里配上月度上限和告警线，每次往 api_calls 写记录时，顺带算一下当月累计花了多少，过了 80% 就发条 Discord 通知。Vyane 的模型选择策略还能做”看着预算来路由”的决策——Anthropic 花到 80%，Opus 降级用 Sonnet，只有设计和审查这类硬活儿才舍得动 Opus；总花销到 90%，全线降到最便宜的可用模型；到 100%，非关键的调用直接停掉。钱包快空了就自动收着点花，不用你半夜爬起来盯账单。
几个实用的决策框架
把三份调研的结论拧成几条干货。
什么任务值得上多 Agent？审查和测试（写的和查的必须分家），多源调研（不同 Agent 搜不同来源再交叉比对），多模型交叉（不同模型互相补盲点）。
什么任务不值得？线性执行的活儿（批量改文件、格式转换），上下文高度咬合的活儿（多 Agent 把上下文切片分发，反而把该连着的信息切断了），低频的一次性活儿（编排那点开销摊不薄，得不偿失）。
自主循环的”什么时候该停”,按靠不靠谱从高到低排：硬超时、硬上限最靠谱，不指望模型自己判断；外部验证器（测试过了、CI 绿了）次之；token 预算靠谱但粒度粗；Promise 标签靠模型自己吐出来，得防着它为了能收工而撒谎；模型自我判断最不靠谱，要么提前撂挑子、要么原地死循环。能用客观尺子量的，就别问模型”你觉得行了没”。
成本控制就一条核心：不上重型平台，不另搞独立监控，把追踪能力缝进你已经在用的调用链路里。对个人开发者来说，最大的开销从来不是 AI API 那张账单，是你伺候那套监控基础设施搭进去的时间。省时间，才是真省钱。