上下文管理的重要性，以及 Harness 编程的注意事项

AI Agent 的能力正在从“回答问题”走向“自动执行任务”。它可以读文件、改代码、运行命令、搜索资料、分析报错，甚至连续多轮自主推进任务。这种模式极大提升了效率，但也引入了一个容易被忽视的问题：上下文管理。

很多用户以为 AI Agent 的成本主要取决于使用时间。实际上并不是。真正决定成本和稳定性的，往往是：

模型调用次数 × 每次携带的上下文长度 × 模型单价 × 工具调用结果规模

这意味着，一个看似只运行了 10 分钟的任务，如果后台执行了几十次工具调用，并且每次请求都携带越来越长的历史内容，就可能在短时间内消耗大量资源。

一、一个真实案例：10 分钟消耗过半积分

这次讨论来自一个真实使用场景。

用户以 198 元购买了 WorkBuddy 一个月会员，会员权益折算为约 2000 积分。随后用户在腾讯 CodeBuddy / WorkBuddy 中执行了一个 AI Agent 编程任务。任务持续时间并不长，大约 10 分钟，但积分账单中出现了 3 次较大的扣分，短时间内消耗了超过一半积分。

用户提交工单后，客服给出的初步解释是：系统日志显示这是正常积分消耗，消耗高的原因主要包括：

1. 操作频次高：短时间内 AI 自动执行了 70 余次工具调用，包括文件修改、命令执行、搜索等。
2. 上下文累积：对话持续未中断，每次请求携带的历史上下文从几千 Token 累积到 10万+ Token，导致单次请求成本急剧上升。
3. 模型成本差异：该时段主要使用了 glm-5.1，积分单价较高。

从用户角度看，问题在于：用户只是提交了一个任务，并不知道后台会自动拆成 70 多次工具调用，也不知道上下文会累积到 10万+ Token，更不知道使用的是高积分单价模型。

因此，这个案例的重点不是简单判断“平台有没有扣错费”，而是揭示了 AI Agent 产品中的一个核心风险：

用户感知到的是一个任务；
系统实际执行的是一串自动化循环；
账单计算依据的是多轮模型调用、工具结果和上下文长度。

如果 Agent 的执行过程不可见、成本不可预估、上下文增长不可控，即使每一次底层调用都符合计费规则，整体体验也可能超出用户的合理预期。

二、这个案例可能哪里失控了

如果客服描述属实，这次高额积分消耗最可能不是由“10 分钟使用时间”造成的，而是由以下几个因素叠加造成的。

1. Agent 循环过密

AI 编程 Agent 通常会经历这样的循环：

理解任务
读取项目结构
读取相关文件
制定修改方案
修改文件
运行命令或测试
读取报错
再次修改
再次验证
总结结果

每一步都可能触发模型请求和工具调用。客服提到 10 分钟内出现 70 余次工具调用，说明后台自动执行密度很高。

这不一定代表系统异常，但如果没有工具调用上限、预算阈值和暂停确认机制，就容易出现成本失控。

2. 上下文滚雪球

客服提到上下文从几千 Token 累积到 10万+ Token，这是最关键的信号。

在 AI Agent 中，上下文不只是聊天记录，还可能包括：

用户需求
历史对话
任务计划
文件内容
搜索结果
命令输出
报错日志
代码 diff
工具调用记录
模型中间状态

如果系统每一轮都把这些内容完整带入模型，而不是做摘要、截断、去重和索引，那么上下文会不断膨胀。到了后期，即使用户没有继续输入很多内容，Agent 内部每一次模型调用也会变得非常昂贵。

这也是为什么 3 次大额扣分可能集中出现在任务后半段：当上下文已经累计到很大时，单次请求的输入成本会明显升高。

3. 工具结果可能被重复注入

代码类 Agent 最容易消耗 Token 的内容包括：

大文件全文
目录扫描结果
搜索结果
测试日志
报错堆栈
代码 diff
多轮工具调用历史

如果 Harness 没有对这些内容做压缩和去重，而是持续把它们塞回模型上下文，就会形成“信息越查越多、每步越来越贵”的局面。

4. 高价模型全程参与

客服提到该时段主要使用了 glm-5.1，积分单价较高。

成熟的 Agent 系统通常应该区分任务阶段：

低价模型：分类、摘要、日志提取、简单判断
中档模型：常规代码修改、普通问答
高价模型：复杂架构决策、关键代码生成、疑难问题分析

如果整个链路都使用高价模型，尤其是在上下文达到数万甚至 10万+ Token 时，成本会快速上升。

5. 缺少用户侧刹车机制

这次案例最值得关注的是用户侧不可见、不可控、无预警。

合理的 Agent 产品，在出现以下情况时应该提醒或暂停：

本任务已调用工具 30 次
本任务上下文已超过 50k Token
预计继续执行将消耗大量积分
当前正在使用高价模型
是否继续？

用户提交一个任务，不等于授权系统无限制拆解、调用和消费。透明的确认机制，是 Agent 产品信任感的基础。

三、上下文管理的核心价值

上下文管理不是简单地“记住更多内容”。恰恰相反，好的上下文管理应该知道：

什么必须保留
什么应该摘要
什么可以丢弃
什么只需要引用位置
什么需要重新读取

一个成熟的 AI Agent 系统，应该避免把所有历史内容无差别塞进模型。它需要像一个优秀工程师一样管理工作记忆。

好的上下文管理至少包括几类能力：

压缩：把旧对话和工具结果总结成短摘要。
截断：对过长日志、搜索结果、命令输出进行限制。
去重：避免重复注入同一个文件、同一段日志、同一次搜索结果。
索引：只把相关代码片段送入模型，而不是整个项目。
分层：区分任务目标、当前状态、历史记录和临时信息。
预算：根据 Token 数、工具调用次数、模型价格控制成本。

上下文管理做得好，Agent 会更稳定、更便宜、更可控。上下文管理做得差，Agent 就容易出现三类问题：

成本暴涨
执行跑偏
响应变慢

四、Harness 编程是什么

这里的 Harness，可以理解为围绕大模型构建的一层“执行框架”或“控制系统”。

模型本身只负责理解和生成，但 Agent 要真正完成任务，还需要 Harness 来管理：

什么时候调用模型
什么时候调用工具
调用哪些工具
工具结果如何返回给模型
上下文如何组织
任务何时暂停
成本如何限制
失败如何重试
用户何时确认

简单说：

LLM 是大脑
Tools 是手脚
Harness 是神经系统和安全控制器

很多 Agent 产品的差异，不只在模型强弱，更在 Harness 设计是否成熟。

一个模型很强，但 Harness 设计不好，也可能出现疯狂调用工具、反复读取文件、上下文无限膨胀、成本不可控的问题。

五、Harness 编程的关键注意事项

1. 必须设置执行预算

Agent 不能无限制自动运行。Harness 应该支持明确预算，例如：

最多调用模型 N 次
最多调用工具 N 次
最多消耗 N 个 Token
最多运行 N 分钟
最多消耗 N 积分

一旦接近预算，就应该暂停并让用户确认。

没有预算控制的 Agent，本质上就是一个可能无限循环的自动化程序。

2. 工具调用要有上限和目的

工具调用不是越多越好。每次工具调用都应该有明确目的：

为什么要读这个文件？
为什么要再次搜索？
为什么要重新运行命令？
这次调用能否改变决策？

如果连续多次工具调用没有带来新信息，Harness 应该判断为低收益循环，并暂停。

常见风险包括：

反复读取同一批文件
反复运行同一个失败命令
反复搜索相似关键词
反复修改同一段代码

这些行为会快速消耗上下文和费用。

3. 工具结果不能原样无限注入

命令输出、日志、搜索结果、文件内容都可能非常长。Harness 不应该把它们完整塞进上下文。

更合理的做法是：

只保留关键错误行
只摘取相关代码片段
只摘要搜索结果
只记录文件路径和变更摘要
长日志默认截断
重复内容引用历史摘要

例如测试失败时，不必把几千行日志全部交给模型。通常只需要：

失败测试名称
错误类型
关键堆栈
相关文件路径
最近一次代码变更

4. 上下文应该分层管理

一个好的 Agent 上下文不应该是一大坨聊天历史，而应该是结构化状态。

可以分成：

任务目标：用户到底要完成什么
当前计划：下一步要做什么
项目事实：已经确认的信息
变更记录：改了哪些文件
问题记录：遇到了什么错误
短期上下文：当前这一步需要的文件片段
历史摘要：之前发生过什么

这样模型每次只读取当前需要的内容，而不是拖着完整历史前进。

5. 高价模型要谨慎使用

不是所有步骤都需要最强模型。

合理的 Harness 应该能根据任务阶段选择模型：

低价模型：分类、摘要、日志提取、简单搜索判断
中档模型：常规代码修改、普通问答
高价模型：复杂架构决策、关键代码生成、疑难问题分析

如果整个 Agent 链路都使用高价模型，尤其是在上下文已经达到数万甚至 10万+ Token 时，成本会非常高。

6. 必须有用户确认机制

当 Agent 即将执行高成本、高风险或不可逆操作时，应该暂停确认。

例如：

工具调用超过 30 次
上下文超过 50k Token
预计消耗超过某个积分阈值
准备使用高价模型
准备批量修改文件
任务运行时间异常增长

用户只提交了一个任务，不代表授权系统无限制拆解、调用和消费。

透明的确认机制，是 Agent 产品信任感的基础。

六、给使用者的经验

这次 WorkBuddy / CodeBuddy 的案例给普通用户和开发者都提供了直接经验。

第一，长任务拆短。

不要把“帮我完成整个项目”交给 Agent 一路跑到底。更稳的方式是：

先分析问题
再制定方案
再修改一个模块
再运行测试
最后总结

第二，先让它计划，不要直接执行。

可以明确说：

先分析，不要修改文件。
先列计划，不要执行命令。
每一步执行前说明原因。
超过 10 次工具调用请暂停。

第三，长会话要及时重开。

如果一个会话已经跑了很久，里面有大量文件、日志、修改记录，后续每一步都可能更贵。阶段完成后新开会话，往往更干净、更省成本。

第四，关注模型选择。

如果任务不复杂，不要默认使用最高价模型。尤其是 Agent 自动执行时，高价模型配合长上下文，消耗会非常快。

第五，要求平台提供明细。

合理的平台应该提供：

模型名称
input token
output token
cache token
工具调用次数
每次调用时间
积分单价
扣费公式
上下文压缩情况
异常重试记录

没有这些信息，用户无法判断消耗是否合理。

第六，发生争议时要抓住三个关键词：

不可见：用户看不到后台每次调用、Token、单价。
不可控：用户没有逐次确认高频工具调用和高价模型使用。
无预警：积分快速消耗时没有暂停或二次确认。

这三个关键词，比单纯说“扣费太贵”更能指出 Agent 产品设计中的问题。

七、结论

AI Agent 的真正难点，不只是让模型更聪明，而是让整个执行系统更可控。

这次案例说明，用户看到的是一个短时间任务，但平台内部可能已经发生了高频工具调用、长上下文累积和高价模型调用。只要 Harness 缺少上下文压缩、工具调用限制、成本预算和用户确认机制，即使底层计费规则没有错误，用户体验仍然可能是不透明和不可控的。

未来优秀的 AI Agent 产品，应该不只是“能做事”，还要做到：

知道自己在做什么
知道什么时候该停
知道哪些信息该保留
知道哪些成本需要提醒用户
知道什么时候必须请求确认

对于开发者来说，编写 Harness 时要把模型当成一个昂贵但强大的执行单元，而不是无限免费的函数调用。

对于用户来说，使用 Agent 时也要意识到：真正贵的不是时间，而是自动循环、长上下文和高价模型叠加后的成本。