
背景Agent 的 Token 花销里有不少是冤枉钱。同一个项目跑过的坑换一次任务又踩一遍上次查清楚的信息这次从头再查一轮。这些轮次本来不该发生但每一步都在烧 Token。业界主流的降本法是剪单次。工具返回太长就压Headroomheadroomlabs-ai/headroom压冗余结构rtkrtk-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 改完前端代码以后需要根据访问方式选择不同的验证流程。两个端口的差异正是这次任务绕路的原因。任务本身很小。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 的能力越来越强成本仍然需要单独管理。让它少犯重复错误把计算资源留给新的问题这就是“减轮次”带来的价值。相关文章阅读从 Agent Harness 到 OS Harness当凭据越过边界时如何阻断ANOLISA AgentSight让 Agent 的每一次“沉默”都无处躲藏AI Agent 时代下一代 Shell 应该长什么样ANOLISA 亮相 WAIC“共赢金砖”论坛入选“智用·人工智能国际公共产品图谱”人和 Agent 第一次共享同一份 CLI 体验 —— ANOLISA v1.0发布你在用 Hermes它也能拥有 ANOLISA 全套能力了阿里云亮出 Agent 基础设施全景图ANOLISA 要做每一个 Agent 的运行底座Agent 越能干你越不敢放手ANOLISA 给它穿上全套防护Agent 烧钱如流水Agentic OS (ANOLISA) 帮你逐笔看清 Token 账单Agentic OS 实战指南手把手教你从 ANOLISA 源码安装阿里云发布 Agentic OS首个面向 Agent 的操作系统—— 完 ——