连续六周每日使用开源桌面Agent Shell的三模型拆分（Haiku三分类器 → Sonnet审查器 → Opus执行器）的真实成本数据与故障记录。

我在个人基础设施上运行了大约6周的模式，想分享实际成本和故障模式的数据。不是理论上的。整个过程在我构建的开源桌面Agent应用内运行（根据子规则，链接在主帖评论中）——扩展生态系统使拆分变得容易。 ## 拆分 - **三分类器 (Haiku 4.5)** — 对每个传入任务首先运行。分类为 `route_directly`、`needs_review`、`block`。返回结构化JSON，无副作用。成本低，可批量处理，独自约70%决策正确。 - **审查器 (Sonnet 4.6)** — 仅在三分类器标记为 `needs_review`（约25%流量）或父Agent置信度低时调用。在任何副作用运行前对Haiku的分类进行“二次意见”检查。捕获约80%的Haiku边缘调用。 - **执行器 (Opus 父Agent)** — 负责编排的规划器。规划、决定哪个子Agent运行、批准副作用、处理面向用户的回复。始终运行。 三者均为Anthropic模型。同一个OAuth令牌覆盖所有三个模型，适用于单个Claude Pro/Max订阅。无需切换供应商，无需管理API密钥。桌面Shell通过一个统一框架将它们连接起来，子Agent定义是纯Markdown文件，而非代码。 ## 运行场景 - **个人邮件分类**: 收到的邮件被分类 → 标记、存档或呈现给我。审查器捕获Haiku会存档的财务/工作邀请邮件。 - **每日新闻简报**: 三分类器将200+条源筛选至15条；审查器排序；执行器综合。 - **Reddit/Gmail/Sheets操作**（那些无聊的副作用工作）。 - **桌面编程会话** — 对于需要观察工具调用时间线的长思考任务，我从终端切换到桌面UI。 ## 成本数据（过去6周，我的实际账单） 没有拆分时，一切都在Opus上运行 → **每月87美元** 的令牌费用。拆分后： - Haiku承担约75%的总令牌，每个令牌成本低于5% - Sonnet承担约20%，每个令牌成本约30% - Opus承担约5%，即规划/批准表面 净费用：**约每月31美元**。下降64%。用户感知质量相同，有时甚至更好，因为审查器会在Haiku误判执行前捕获它们。 ## 出现的问题 1. **三分类器上下文膨胀**。Haiku每个令牌便宜，但如果你盲目地将整个收件箱交给它，每个任务并不便宜。我将每次三分类调用的输入令牌限制为邮件正文+标题的500个令牌。任何更长内容，父Agent先做摘要。 2. **审查器反射**。早期，审查器大约15%的时间会推翻Haiku的正确判断，因为Sonnet默认“更谨慎”。修复：明确提示——“你的角色是发现错误分类，而不是从头重新判断——除非有具体理由，否则同意Haiku。” 3. **审批门控延迟**。执行器在副作用（删除、发送、标记）上暂停。当我在手机上时，通过Telegram桥接的审批按钮往返需要5–30秒。对邮件可接受，但破坏了实时聊天。现在：对于实时回合，子Agent拥有预批准的权限集，执行器无需询问。 4. **子Agent失控**。有一次Haiku在父Agent注意到之前递归调用了8个子Agent。设置上限：`agentMaxTurns: 16`，并在令牌池溢出时硬终止。 ## 统一框架的重要性 拆分容易*描述*，但从头开始连接却很麻烦——你需要覆盖所有三个模型层的OAuth、子Agent隔离、审批门控、通过嵌套Agent的流式传输。我在一个桌面应用中运行这些，该应用将连接作为默认值提供：将两个Markdown文件放入 `~/.pi/agent/agents/`，父Agent会拾取它们，完成。这就是使这个实验足够便宜以实际运行的原因。 ## 我接下来会改变什么 - 将三分类器从Haiku 4.5切换为一个针对确定性类别微调的本地7B模型。大多数邮件类别是稳定的；微调已经在待办清单上一个月了。 - 从“审查器在分歧时升级到执行器”改为“审查器可以写一段异议，执行器在规划步骤中读取”。这比二元覆盖更好。