一、一次调研，就能把我的 Token 套餐打爆
我用 Claude Code Agent Teams 搭了一支调研团队。Lead 负责理解问题、安排工作，其他角色分别取材、整理证据、提出主张、进行红蓝对抗，最后交给审计角色核验，形成研究报告。
这套设计里有几个我很看重的地方：Lead 可以按需调动不同的子 Agent；材料、主张和质询都有对应的产物；红方能够提出反证，审计角色也会追问结论到底有没有依据。我希望它能把一个复杂课题从头做到尾，让我把精力放在问题和判断上。
但真正用起来，Token 消耗实在太大了。最直接的感受就是：运行一次调研，套餐就要被打爆。
于是我开始认真想办法省 Token。给系统加了各种限制，又一轮接一轮地调整。后来出现了一个让我很难接受的结果：Token 还是没省下来，执行流程却被改得几乎无法使用。
二、我想到的办法，是通过 Harness 把消耗管起来
这里需要先介绍一下 Harness。在这支调研团队里，它是围绕 Agent 执行工作的工程环境：规定角色能做什么，检查工具调用，保存任务进度，记录消耗，并提供处理材料的脚本。
Claude Code 提供了派工、消息和工具执行等原生能力，我在这些能力上叠加了自己的流程和控制措施。具体落地时，Harness 由几类东西共同组成。
| 实现方式 |
在这支团队里做什么 |
| Markdown 角色说明与流程文档 |
定义职责、工作步骤、交接要求和产物格式 |
| JSON 配置 |
连接 Hook 入口，保存预算等控制参数 |
| Hook |
在工具执行前后、失败以及任务生命周期节点触发检查和记录 |
| Shell 脚本 |
找到工作目录，选择 Python 环境，启动处理程序 |
| Python 程序 |
执行权限检查、计量和恢复，处理正文提取、证据定位、卡片组装等机械工作 |
| 状态文件、产物和日志 |
保存进度与已有材料，支持恢复、复用和过程分析 |
例如，一次工具调用可以先触发 Hook，由 Shell 入口启动 Python 程序。程序读取任务状态，检查这次操作是否符合规则，再把决定或提醒返回给宿主。执行后的结果、失败信息和消耗，也可以通过相应事件记录下来。
有了这些入口，我当时的想法很直接：既然 Agent 花得太多，就在执行过程中检查累计用量。超过预算，就限制后续操作。再把预算分给不同角色、不同阶段，给最后的审计和成稿预留一部分资源。
这个办法看上去很工程化：参数明确，规则可执行，超标就有反馈。
图 1：Lead 统筹研究流程，Harness 通过文档、配置、Hook、脚本和状态记录作用于各阶段。为便于阅读，图中合并了部分预审和盲写步骤。
三、改了很多版，调研却越来越难继续
问题在真实运行中逐渐暴露出来。Agent 工作一段时间，就达到项目设置的额度，后续调用被拦住。Lead 提示需要再开一个 session，也就是新的会话。新会话接着做，没多久又超标，再次停下。
我不断输入"继续"，不断处理这些恢复问题。有一次，Agent 调研跑了五个小时还没有结束。材料已经积累了一批，主张也有了，但整个流程就是走不到交付。
我调整过总额度、角色配额、阶段比例和收尾预留，也优化过阻断提示，试图让恢复更友好。这些修改解决了一些局部问题，却始终沿用了同一个前提：只要超出估算，就应该停下来。
更麻烦的是，中断本身也会花 Token。换一个会话，就要恢复上下文、说明做到了哪里、检查哪些文件可以继续用。遇到权限冲突，还要解释报错、重新安排角色，甚至重新生产已有材料。
有一个例子让我印象很深。核对两次运行的产物时，我发现 25 张证据卡的哈希全部相同，内容没有变化。但在新的运行目录里，模型仍重新生成了约 5 万字符的组装材料。路径换了，内容没换，模型却又搬运了一遍。
这让我开始怀疑：限制一次运行的消耗，究竟能在多大程度上节省一整个课题的成本？如果每次达到上限都要重新开始一部分工作，那么省下的额度，很可能又花在了恢复和重做上。
我看到的实际情况是，控制越来越细，用户需要处理的中断也越来越多。系统忙着遵守限制，调研却迟迟没有完成。
四、我突然想明白：先完成调研，再谈怎样省下来
后来，我意识到自己的目标设得有些简单粗暴了。
最终目标还是要把调研做完。如果完成这项工作确实需要较高的 Token 消耗，就应该面对这个成本。可以提醒，但不能简单地因为超标，就中断整个任务。
这个认识改变了后面的优化方向。首先，默认预算改成预测和提醒。超出预计时，Lead 可以说明原因，结合剩余工作更新预测，沿着原任务继续执行。初始估算、历史消耗和调整记录都保留下来，不靠新开会话重新计算一份额度。
成本仍然需要管理。如果用户明确要求一个绝不能突破的上限，系统应当执行这个约束。但在我这次希望完整完成调研的使用场景里，估算偏差不应该自动变成停止工作的理由。
其次，判断一项优化是否有效，要把视野放到完整课题上。除了单次调用用了多少，还要看最后有没有交付，经历了多少次恢复，有没有重做材料，需要我介入多少次。
预算超预计、工具失败、证据不足、供应商限流，也需要分别处理。成本偏差可以提醒；工具错误要定位；证据缺口需要补检；外部服务暂时不可用，就保留进度，按条件恢复。它们不应该都导向同一个"整个调研停下来"的结果。
图 2：默认成本控制从"触限—阻断—重开会话"转向"提醒—沿原进度继续"。权限和质量检查继续生效，外部服务限制仍需单独处理。
五、把优化落到 Agent 真正做的每一步
目标调整以后，Token 仍然是我关心的指标，但我更想知道它具体花在了哪里。
先把重复工作看清楚
我开始从日志里观察每个角色、每类操作的消耗，寻找重复请求、长文本反复写入、无变化的状态查询，以及错误之后的整批重做。
这些分析尽量交给脚本完成，按需要运行，不再安排一个常驻 Agent 持续询问进度。发现重复以后，还要结合当时的输入和任务目的判断。审计员为了独立核验而再次阅读证据，有它的必要；同一份材料因为目录变了而被重新抄写，就值得追问。
采用日志工具也是个好方法，但需要把日志工具和 AI 运行环境打通，以便 AI 能够主动对日志进行分析。
能用代码执行的工作，尽量交给代码
这是多轮优化里，我越来越明确的一条原则。
提取网页正文、定位引文、计算哈希、组装证据卡、生成清单、批量回写审定后的修改、统计用量——这些工作有明确的输入和规则，适合交给 Python 代码。模型负责选择材料、理解证据、解释范围和形成判断。
例如，原始网页里可能包含大量脚本、样式和页面结构。把整份 HTML 交给模型，里面相当一部分内容与研究问题无关。在一个实际网页样本中，代码抽取文本后，材料字符量减少了约 97.7%，证据卡引用的三段文字仍然能够定位。
这是材料字符量的变化，不能直接换算成整个任务节省了多少 Token。但它指出了一类具体的优化空间：进入模型之前，可以先用程序减少材料里的无关负担。
组装材料也一样。模型可以给出研究判断和必要字段，由脚本处理行号、哈希、格式和文件写入。已有内容能够按规则复用，就不必让模型逐字重新生成，再交给另一个角色核对格式。
实现时，我会优先找高频、稳定、重复的动作，复用已有工具。脚本本身也有维护成本，不值得为每个临时动作重新生成一整套程序。
脚本存在，还要能顺畅地用起来
我也发现过一种矛盾：角色说明要求使用证据定位脚本，实际工具入口或权限检查却限制了调用。于是请求绕到 Lead，Lead 代查，再把结果转回来。一个原本想减少消耗的工具，反而增加了传话和解释。
这就要求把整条调用路径一起核对：角色是否拥有工具，Hook 是否允许相应操作，参数是否清楚，返回结果是否围绕需要的证据。不能只改了脚本，就认定 Agent 已经能够顺畅使用它。
我还调整了证据定位的输出，让返回窗口围绕命中的句子，减少为了找到一句话而反复读取长文件的必要。
故障局部处理，Harness 自己也要减负
一次读取失败，不应该轻易演变成整组任务重派。恢复前先检查目标文件和已有产物；派工或消息失败时，先核对是否已经送达，避免把已经执行的工作再做一遍。
与此同时，Harness 自身也需要接受检查。我发现，常规工具调用前的计量逻辑会反复解析已经存在的历史日志。任务越长，这部分重复工作就越值得关注。
后续实现增加了缓存和增量解析：日志没有变化时复用结果，有新增内容时处理新增部分，封账时再完整复算。这主要针对计算、文件读取和等待开销，需要与模型 Token 分开观察。
这些改动让我对"节省成本"有了更具体的理解。可以优化的对象，不只是一条额度参数，还包括输入材料、工具返回、角色交接、错误恢复，以及运行环境自己执行的每一步。
六、最近一次调研终于跑完了
经过这些调整，最近一次调研终于沿着完整流程跑完，交付了报告。
这个结果背后，也有不同层面的验证。在多轮优化中的一次控制层验证里，116 项测试和 6 组机械场景通过，覆盖了预算提醒、角色权限、盲写隔离、恢复和独立验收等行为。
其中检查过一些很具体的情形：超过预计后，正常研究能否继续；盲写角色能否被阻止读取已有蓝稿；没有独立验收时，任务能否被错误地标记为完成。实际审计也曾发现数字区间被写成定值、匿名企业被误认等问题，并留下修正和复核记录。
在后来完成的那次调研中，Lead 在同一任务内两次更新了预算预测，保留此前的消耗和进度，最终完成交付。对我而言，这比不断收到"请重新开启会话"有意义得多。
回头看，几轮优化带来的变化可以整理成下面这张表。
| 对比维度 |
逐轮优化带来的变化 |
| Harness 的重点 |
从围绕额度和阻断调整，转向过程观测、工具支持和持续执行 |
| 成本控制 |
默认超标限制后续操作，改为提醒并允许在原任务更新预测 |
| 材料处理 |
增加正文抽取、定位与组装工具；一个网页样本的字符量减少约 97.7% |
| 可靠性与可控性 |
逐步补齐权限、恢复和验收检查；一轮控制层验证通过 116 项测试与 6 组机械场景 |
| 故障与运行开销 |
增加局部恢复、日志缓存与增量解析，减少整批重做和反复扫描的必要 |
| 实际交付 |
从多次中断、迟迟无法完成，到后来一次调研完整交付 |
这些结果来自连续迭代中的局部验证和真实运行，没有做整项调研的同条件成本对照，因此我不会把它们汇总成一个"总体提效百分比"。它们已经足以支持这次认识上的变化，也让我知道下一步该往哪里继续找问题。
我以后还是会看 Token，但会继续追问：它花在了哪一步，那一步推进了什么，其中哪些工作可以直接交给代码？
对 Agent 执行过程进行跟踪、评测、优化，比简单粗暴的阻断更加有效。 如果你也在用类似的方式搭建自动化调研流程，不妨参考社区里沉淀的 技术文档 和避坑记录，少走一些弯路。
发表于 22 分钟前
|
查看: 4|
回复: 0
