，实际的 agent 开发中，这些占比有多少，怎么感觉大部分工作还是盯着工具做文章

回复 群友 8714： 你的感觉基本是对的，工具那块占比确实最大。但更准确的说法是：你盯着工具做文章的时候，相当一部分时间其实就是在做上下文工程，这两件事在很多项目里压根拆不开。 先给个量级感（这是我自己的经验判断，不是统计口径）：工具设计及其周边，包括 schema、返回裁剪、错误信息、工具集收敛，大概占三到四成；评测和看 trace，也就是造 case、跑回归、定位"为什么这次又选错工具"，占三成上下；上下文管理本身（压缩、检索、记忆、缓存友好）两成左右；剩下的才是编排、框架、多 agent 这类。而且长任务里上下文那块会明显吃重，短任务里你几乎碰不到它。 给几个具体例子。 例子一，工具返回太大。一个查订单的 agent，工具直接把后端完整 JSON 甩回来，嵌套三层三千多 token，模型实际只用到订单号、状态、金额、时间四个字段。改成在工具内部先裁剪，只回这几个字段加一句摘要，单次调用从三千降到四百，跑十轮省下来的预算够多撑好几轮对话。改的是工具，收益直接落在上下文上。 例子二，工具集臃肿。二十个工具里有三个职责重叠，查用户、查客户、查会员，模型在边界场景反复选错。合并成五个边界清晰的工具，成功率立刻上去。Anthropic 那篇 context engineering 里说得很直白：人类工程师都说不清该用哪个工具时，别指望模型更强。而这个"说不清"的另一面，就是这几个工具的 description 在系统提示词里占了一大块。 例子三，错误信息。工具失败返回 Error 500，模型只能瞎猜重试；返回"参数 date 需要 YYYY-MM-DD 格式，你传的是 2026/9/15"，下一次调用它自己就改对了。错误信息本质上是喂给模型下一轮的 prompt，但很多团队是最后才想起来动它。 至于你问的压缩策略本身，生产里真正需要动它的信号很明确：任务 horizon 变长。一次会话要跑几十轮、上百次工具调用时，压缩就是必须的。而且常见做法不是一上来就全文摘要，先做最轻的一层——清理历史深处的工具返回原文。那个结果模型在五十步之前看过一次，后面再也用不到，留着纯粹占注意力预算。Claude Code 的 compaction 是先让模型榨一版保留架构决策和未解 bug 的摘要，再带上最近访问的几个文件重开一个窗口；更长的任务还会让 agent 自己写 NOTES.md 这类笔记，压缩完读自己的笔记接着跑。 体感"大部分时间在工具上"还有个结构性原因：模型本身你改不了，能施加确定性控制的地方只有三处——给它什么输入、它允许调什么、它拿回什么结果。工具横跨了后两样，所以它天然是杠杆最大的那个点。上下文压缩更像是系统跑起来之后的维护工作：任务短时它几乎不存在，任务一长、流量一大，它突然就变成主要矛盾。 所以与其说是"只有工具值得做"，不如说这两件事本来就在同一层。能把工具设计讲清楚的人，上下文通常也差不到哪去；反过来，一个 agent 效果差，很多情况下不是模型不行，是工具返回把上下文喂脏了。