Agent省钱新思路：压缩Prompt之外，先让Agent少踩坑

背景

Agent 消耗的 Token 里，有一部分花得并不值。同一个项目里踩过的坑，换个任务又得再踩一遍；上次已经查明白的信息，这次还得从头再查。这些轮次原本可以不出现，可每一步都在消耗 Token。

业内常见的省钱办法是压缩单次调用。工具返回的内容太长就压一压，Headroom（headroomlabs-ai/headroom）负责压掉冗余结构，rtk（rtk-ai/rtk）过滤 shell 输出；历史记录太长就截断，Claude Code 的 compaction、LangChain 的 trim_messages 用滑动窗口和摘要来处理。每次交互少发一些内容，确实能省下成本。不过这些手段针对的是单次调用的体积，管不了轮次本身该不该发生。

AgentSight 盯的是后面这一层。先把钱花在哪里看清楚，再从轨迹里把经验积累下来，让不该出现的轮次不再出现。它和压缩单次调用的做法互为补充，并不冲突。

AgentSight 解决方案

AgentSight 属于智能体操作系统 Agentic OS 的可观测性组件，装在用户自己的机器上。按当前版本的默认配置，轨迹数据在本机完成解析并落盘。

当前版本接入时不需要改动 Agent 代码。macOS 上靠扫描本地 JSONL 会话文件来生成轨迹，不用 root 权限。Linux 默认同样走不加载 eBPF 的本地会话采集模式；如果明确开启完整 eBPF 管线，则需要 root、Linux 5.8 以上内核以及 BTF 等前置条件。产品文档还提到，Kubernetes 和 Docker 环境能够识别容器身份，目前适配 Claude Code、Codex CLI 和 Qwen Code。

轨迹优化分析的整体架构如下：

采集到的原始数据要先做完整重组。完整 eBPF 模式在内核侧获取流量，应用层同时解析日志，两路数据再合并到一起。HTTP/1.x、HTTP/2 和 SSE 里分散的请求与响应，会被还原成单次调用、会话轮次和完整会话。按当前产品说明，内置解析器覆盖 OpenAI、Anthropic、阿里云百炼以及 OpenAI 兼容端点，输出遵循 OpenTelemetry GenAI 语义约定与 ATIF v1.7 标准。轨迹内容包含提示词、模型输出、工具调用参数和结果，同时关联进程树、文件写入和网络行为。这样一来，使用者可以对照着看：一次 LLM 调用触发了哪些系统动作，Agent 又是根据什么信息走到下一步。

AgentSight 在轨迹重组结束后，会围绕成本、性能、准确性做三项分析。成本这块逐次拆开上下文窗口，借 Token 火焰图展示历史内容被反复重放带来的放大效应，同时定位重复调用、可压缩的提示词以及无效轮次。性能分析则将耗时划为模型等待、工具执行与空闲间隙，让使用者看清究竟是哪一环在拖慢任务。准确性分析以语义识别为手段排查问题，把缺陷归到 Skill、工具或上下文头上，多轮原地打转的情形同样能识别出来。此外，系统内置 18 类会话中断检测和开箱即用的仪表盘，可按时间、Agent 和会话逐层往下查看。

分析结束后，报告会把建议落到具体调用上，分别说明 Skill 定义、上下文组织和 Prompt 结构可以怎么调。结果会留存下来，修改后重新运行同类任务，就能直接比较前后的数据。所有建议都以只读方式给出，采不采用由使用者自己决定。

使用流程

实际操作分三步：选中一条会话、发起分析、查看报告。下面用一条真实会话把整个过程走一遍。

打开 Dashboard 的会话列表页，系统按时间展示已经采集到的 Agent 会话。页面上方能按采集来源和 Agent 类型筛选，也支持语义搜索。输入“修复构建报错”这类自然语言，就能找到相关会话。定位到目标后，点右侧的分析按钮，AgentSight 会启动专门的优化分析 Agent，从头把这条会话检查一遍。

分析结束就进入报告页。页面顶部先给出轨迹摘要，用几句话说明这次会话做了什么、经过如何、最后有没有完成。下面是基础统计，包括问题数、工具调用次数、总耗时和事件数。

准确性部分把检测到的缺陷列成表格。每条记录含现象描述、缺陷类型、归因对象、修复位置和置信度，缺陷类型分为 Workflow、Tool Error 和 Skill Gap。展开任意一条，能看到完整的根因分析。右侧还给出可复制的优化提示词，可以直接拿去修改 Skill 定义或 AGENTS.md。

切到性能页，耗时被拆成模型推理、工具执行和用户空闲三块。一张图就能看出各部分占多大比例，右侧的“最慢调用”表按耗时排序，列出拖慢任务的工具和对应命令。工具执行慢就查工具，模型等待时间长就查上下文或模型选择。用户空闲占比最高时，也能及时排除 Agent 本身的问题。

成本页展示总 Token 数和峰值 Context 大小。下方的堆叠柱状图按步骤重放上下文窗口，并把它拆成静态区域、用户提示词、助手历史输出和工具返回。点任意一步，都能看到精确的构成比例。红色折线记录每一步的输出 Token。某一步上下文突然变大，输出却没推动任务，这种地方通常值得继续查。页面底部的浪费分析会识别重复调用、可压缩提示词和无效轮次，并估算能省下多少 Token。

拿到报告后，下一步是看问题出在哪。准确性问题归因到 Skill，就去改 Skill 定义；性能瓶颈落在工具调用，就逐项处理最慢调用。成本分析如果发现能长期复用的项目经验，可以写进 AGENTS.md，让后续同类任务少走几轮。改完再跑一次，前后差异会直接显示在 Dashboard 里。

案例分析

下面用一个真实案例，说明“减轮次”怎么落到具体任务上。

这次案例出自 AgentSight 自己的前端开发。项目走的是前后端混合架构，前端访问分两条路：:3004 是独立的 Vite 开发服务器，:7396 则用来展示嵌进 Rust 二进制的构建产物。Agent 改完前端代码，得按访问方式挑不同的验证流程，两个端口不一样，恰恰是这回绕远的原因。任务本身不大：在 AgentSight 的会话列表页，给 AGENT 列旁边那些带子代理的会话加一个数量徽章，改动都集中在 AgentSessionsPage.tsx。

Agent 写完代码，跑到 :7396 上验证。页面没出现最新改动，它就开始查缓存、查构建产物、查打包流程，来回折腾了好几轮。最后才弄明白：:7396 的前端被打包进 Rust 二进制，得先执行 build:embed 和 cargo build 才会更新。换到 :3004 的开发服务器，徽章已经正常显示了。

这段弯路花了多少，分析报告里有记录。该次测试共消耗 36K Token，含 18 步 LLM 调用、21 次工具调用，总耗时 370 秒。Context Window 的堆叠柱状图从第 4 步起明显变大，Agent 正是在那里开始朝错误方向排查。峰值 Context 达到 3.4K。到第 17 步，工具输出占了上下文的 63%，其中相当一部分是之前留下的截图和命令返回。

浪费分析把这个情况判定为高置信度的“可预知坑”，还给出了一条能直接照着执行的优化提示词：“前端开发验证优先使用 :3004 开发服务器。没有执行 build:embed 和 cargo build 时，不要在嵌入式前端 :7396 上验证改动。”

这类经验适合写进 AGENTS.md。同样的前端任务以后还会遇到，两个端口的差异又属于模型事先不可能知道的项目知识；浪费分析给出的动作也够具体，能直接改掉下一次的验证顺序。经验规则得写成具体动作。“注意前端验证环境”只是提醒 Agent 留个心；“前端验证走 :3004，未重新构建时不要检查 :7396”已经告诉它下一步该干什么，后者在任务里更容易落地。

把规则写进 AGENTS.md，再跑一遍同样的任务。Agent 直接选了正确的验证方式，轨迹摘要收敛成五个关键阶段，之前那套排查没有再出现。

复测结果：总 Token 从 36K 降到 8.9K，减少约 75%；LLM 调用从 18 步降到 8 步，耗时从 370 秒降到 130 秒，峰值 Context 从 3.4K 降到 1.6K。柱状图中段没有再冒出异常增长，各步上下文保持平稳。浪费分析评估了一项候选，没发现还有值得继续处理的问题。

写在最后

压缩工具返回、截断历史上下文，能让每一步少花点 Token。AgentSight 则继续往前一步，去管调用次数：先找出 Token 花在哪里，再把能复用的经验留给后面的任务，让已知的弯路少走几遍。这件事可以反复做——跑任务、看报告、写下经验，再用同类任务复测。每多一条有效规则，后续任务就多一条明确的行动依据；经验攒起来，Agent 重复犯错的机会变少，Token 开销也会跟着降。

Agent 越来越能干，成本还是得单独管。让它少犯重复的错，把算力留给新问题，这就是“减轮次”的价值。