企业官网建设流程全解析

Agent 跑一个任务，Token 账单里有一大半花在了"重复读同样的东西"上——这不是模型的问题，是架构的问题。NVIDIA 开源的 SoL-Pi 就是冲着这块冗余去的，它把 Agent 执行过程中反复出现的上下文、工具调用描述、历史轨迹做了结构化复用，让同一份信息不必在每一轮推理里被重新编码一遍。如果你正在做 Agent 开发、被 Token 用量压得喘不过气，或者单纯好奇"省 Token"这件事到底能省到什么程度，这篇内容会把 SoL-Pi 的思路、Harness 的角色、以及实际能落地的优化手段拆开讲清楚。

1. SoL-Pi 到底在解决 Agent 的哪一块浪费

1.1 先搞清楚 Agent 的 Token 都花在哪了

很多人第一次看 Agent 的账单会懵：明明用户只问了一句话，为什么消耗了几万 Token？拆开看就明白了。一个典型的 Agent 循环里，每一轮推理都要把系统提示词、工具定义、历史对话、中间观察结果全部重新塞进上下文。假设系统提示词加工具定义固定占 3000 Token，任务跑了 15 轮，光这部分固定开销就是 45000 Token，而真正"新产生"的信息可能只有几千 Token。

这就是所谓的重复开销（redundant overhead）。它有几个典型来源：

• 固定前缀重复：系统提示、工具 schema、few-shot 示例，每轮都在重复编码。
• 历史轨迹重复：前面几轮的思考和工具返回结果，被原封不动地带着往后传。
• 工具描述重复：同一个工具的能力说明，在多轮里被反复读取。
• 观察结果冗余：工具返回的大段原始数据（比如一整页 HTML），其实只有几行有用。

SoL-Pi 的切入点，就是把这些"每轮都要重新过一遍"的东西，从"每次重新计算"变成"一次构建、多次复用"。

1.2 SoL-Pi 的核心思路：把重复的部分"固化"下来

SoL-Pi 这个名字里的 "SoL" 可以理解为一种分层/结构化的组织方式，"Pi" 则指向策略或规划层面。它做的事情本质上是给 Agent 的执行过程建立一套可复用的中间表示。

打个比方。传统 Agent 每轮推理，就像每次做饭都从"去菜市场买菜"开始，哪怕你昨天已经买好了同样的菜。SoL-Pi 的做法是：把"已经确定不变的食材"提前备好、贴上标签、放进冰箱，下一轮直接取用，只处理"这一轮真正新增的那道菜"。

具体到技术层面，它大致做了这几件事：

• 上下文分层：把上下文拆成"稳定层"（系统提示、工具定义）和"动态层"（本轮新增的观察、思考），稳定层只编码一次。
• 轨迹压缩：对历史轨迹做摘要化处理，保留决策关键点，丢弃冗余的中间态。
• 工具调用缓存：相同参数的重复工具调用，直接命中缓存结果，不再走一遍完整推理。
• 结构化复用：把工具返回结果解析成结构化字段，只把相关字段喂回模型。

注意：SoL-Pi 不是"魔法压缩"，它省的是结构性冗余，不是把有用信息也砍掉。理解这一点很关键，否则你会在调参时把关键上下文一起压没了，导致 Agent 变傻。

1.3 为什么这件事值得 NVIDIA 专门开源

NVIDIA 做这件事的动机其实很直接：Agent 是当前算力消耗的大头之一，而 Token 消耗直接对应推理算力。如果能把重复开销砍掉 30% 到 50%，意味着同样的硬件能跑更多 Agent 任务，或者同样的任务成本直接下降。

从工程角度看，SoL-Pi 的价值不在于某个单点技巧，而在于它把"省 Token"这件事系统化了。市面上很多优化是零散的——有人手动精简 prompt，有人写个缓存层，有人做结果截断。SoL-Pi 提供的是一个相对完整的框架，让你不用自己从零拼装。

对开发者来说，最实际的意义是：你可以拿它当参考架构，看看一个成熟的 Agent 执行框架是怎么组织上下文、怎么管理轨迹、怎么处理工具调用的。哪怕你不用它的代码，这套思路也能直接迁移到自己的项目里。

2. Harness 在 Agent 里扮演什么角色，和 SoL-Pi 什么关系

2.1 Harness 不是 Agent，是 Agent 的"跑道"

热词里反复出现 "harness" 和 "harness 和 agent 区别"，说明很多人对这两个概念是混的。用一句话说清楚：Agent 是跑的人，Harness 是跑道和裁判。

Harness 负责的是 Agent 运行所需的那套"外围设施"：

• 执行循环管理：什么时候调用模型、什么时候执行工具、什么时候结束。
• 上下文组装：把系统提示、历史、工具结果拼成模型能吃的输入。
• 工具调度：解析模型输出的工具调用意图，实际去执行，再把结果塞回去。
• 状态与错误处理：超时、重试、异常捕获、循环终止条件。
• 可观测性：记录每一步的输入输出，方便调试和计费。

Agent 本身更偏向"决策逻辑"——它决定下一步做什么。Harness 则是把决策落地的那套工程骨架。

2.2 SoL-Pi 和 Harness 的配合关系

SoL-Pi 的优化点，绝大部分落在 Harness 这一层。因为重复开销恰恰是 Harness 在组装上下文时产生的。所以两者的关系是：

理解这层关系后你会发现：想省 Token，改 Harness 比改模型有效得多。模型你换不了，但 Harness 是你自己写的，每一处上下文拼接都是优化机会。

2.3 一个容易踩的坑：Harness 缓存和语义正确性

我在实际项目里踩过一个坑，值得单独说。当时为了省 Token，给工具调用加了一层"相同参数直接返回缓存"的逻辑。结果遇到一个查询类工具，参数一样但底层数据变了（比如查库存，参数是商品 ID，但库存实时变动），缓存直接返回了旧值，Agent 基于错误数据做了决策。

教训是：缓存要区分"幂等"和"非幂等"。纯计算类、静态查询类工具可以缓存；涉及实时状态、有副作用的工具绝对不能盲目缓存。SoL-Pi 这类框架在设计缓存策略时，通常会让开发者显式标注工具的可缓存性，而不是一刀切。

提示：给工具打标签时，至少分三类——可缓存（纯读、静态）、条件缓存（读但有时效）、不可缓存（写、有副作用）。这个分类决定了你的 Harness 能省多少、以及会不会省出 bug。

3. 把重复开销真正省下来的几个实操手段

3.1 上下文分层：稳定层只编码一次

这是最直接、收益最明显的一招。做法是把上下文明确切成两层：

• 稳定层：系统提示词、工具定义、固定的 few-shot 示例、角色设定。这些在整个会话里几乎不变。
• 动态层：用户输入、本轮工具返回、模型新产生的思考。

关键在于，如果你的推理后端支持prompt caching（很多主流推理服务都支持前缀缓存），那么把稳定层放在最前面、且保持字节级不变，就能命中缓存，这部分 Token 的计费会大幅降低甚至免费。

实操要点：

1. 稳定层内容一个字都不要变。哪怕多一个空格、换一个标点，缓存就失效了。
2. 动态内容永远追加在稳定层之后，不要插到中间。
3. 工具定义按固定顺序排列，不要每轮重新排序。

我实测过一个客服 Agent，光是把工具定义顺序固定、系统提示去掉动态时间戳，缓存命中率从 40% 出头提到了 85% 以上，Token 成本直接砍半。

3.2 轨迹压缩：别把整本日记都带着走

Agent 跑长任务时，历史轨迹会越来越长。很多人图省事，直接把所有历史原样往后传，结果第 20 轮的时候，光历史就占了几万 Token。

正确的做法是分级压缩：

• 最近 N 轮：保留完整内容，因为模型需要细节做决策。
• 较早的轮次：压缩成摘要，只保留"做了什么决策、得到什么结论"。
• 更早的轮次：进一步压缩成一句话，甚至只保留关键实体和状态。

这里有个经验值：最近 3 到 5 轮保留原文，5 到 15 轮做摘要，15 轮以上只留结论。具体阈值要看任务复杂度，但核心原则是——越久远的信息，越应该被压缩成"结论"而非"过程"。

注意：压缩不是简单截断。截断会丢掉关键上下文导致 Agent 重复劳动。摘要要保留"决策依据"，比如"用户已确认地址是 X""库存查询显示 Y 缺货"，这些是后续决策的锚点。

3.3 工具结果结构化：只喂有用的字段

工具返回的原始数据往往很"胖"。比如一个网页抓取工具返回整页 HTML，一个数据库查询返回 50 个字段，但 Agent 真正需要的可能只有 3 个。

SoL-Pi 思路里很重要的一点，就是在工具返回和模型输入之间加一层结构化解析：

# 反面例子：直接把原始结果塞回去 raw_result = fetch_page(url) # 返回 200KB HTML context.append(raw_result) # 200KB 全进上下文 # 正确做法：解析出关键字段 parsed = { "title": extract_title(raw_result), "price": extract_price(raw_result), "stock": extract_stock(raw_result), } context.append(json.dumps(parsed)) # 只进几百字节

这一层解析可以用规则、正则，也可以用一个小模型做抽取。收益非常可观——我见过一个电商比价 Agent，加了这层解析后，单次任务的 Token 从 8 万降到 2 万出头。

3.4 重复工具调用去重：同一件事别做两遍

Agent 有个常见毛病：在推理过程中反复调用同一个工具、传同样的参数。比如反复查同一个订单状态，反复读同一个文件。

Harness 层可以加一个调用指纹机制：

• 对每次工具调用生成指纹（工具名 + 规范化参数）。
• 在会话内维护一个指纹到结果的映射。
• 命中指纹时，直接返回缓存结果，并明确告诉模型"这是缓存结果"。

这里要小心前面提到的幂等性问题。我的做法是给每个工具配一个cacheable标志，只有标记为可缓存的工具才走指纹去重。

4. 省 Token 的边界：哪些能省，哪些省了会出事

4.1 省 Token 不等于无脑压缩

优化做到一定程度，一定会遇到"再压就变傻"的临界点。这个临界点因任务而异，但有几个信号可以帮你判断：

• Agent 开始重复问已经回答过的问题——说明历史压缩过头，丢了关键状态。
• Agent做出和之前矛盾的决策——说明决策依据被压没了。
• 工具调用参数明显错误——说明工具定义或上下文被破坏。

遇到这些信号，说明你压过头了，要往回退。我的经验是：先压最没信息量的部分（原始 HTML、冗余日志、重复的工具描述），最后才动历史轨迹和决策依据。

4.2 不同任务类型的省 Token 空间差异很大

不是所有 Agent 都能省出同样的比例。大致可以分几类：

看这张表你会发现，多轮工具调用类 Agent 是省 Token 的主战场，因为它的重复开销天然最高。如果你的 Agent 属于这一类，投入优化 Harness 的回报会非常明显。

4.3 一个反直觉的结论：有时候多花 Token 反而更省

这话听起来矛盾，但实际项目中经常遇到。比如：

• 为了省 Token 把工具结果压得太狠，导致 Agent 判断失误，多跑了好几轮才纠正，总消耗反而更高。
• 为了省 Token 不做充分的 few-shot，导致模型输出格式错误，反复重试。

所以优化的目标不是"单轮 Token 最少"，而是**"完成任务的总 Token 最少"**。这个视角的转换很重要，很多新手会陷进"每轮都要压到极致"的误区。

提示：衡量优化效果，一定要看端到端指标——任务成功率、平均总 Token、平均轮次。只看单轮 Token 会误导你。

5. 从 SoL-Pi 能学到什么可迁移的工程经验

5.1 把"省"做成架构，而不是补丁

SoL-Pi 最值得学的地方，是它把 Token 优化当成架构设计的一部分，而不是事后打的补丁。很多团队的做法是：先写个能跑的 Agent，发现账单太高，再到处加缓存、加截断，结果代码里全是零散的优化逻辑，维护起来一团糟。

更好的做法是从一开始就在 Harness 里设计好分层：

• 上下文组装器（负责分层和缓存）
• 轨迹管理器（负责压缩和摘要）
• 工具调度器（负责去重和结构化）
• 可观测层（负责计量和调试）

每个模块职责清晰，优化逻辑内聚，后续调整也方便。

5.2 可观测性先行：不知道钱花哪了就没法省

我强烈建议在做任何优化之前，先把计量和追踪做起来。具体要能回答：

• 每一轮推理消耗了多少 Token？
• 其中稳定层、历史、工具结果各占多少？
• 哪些工具调用最频繁、返回最大？
• 哪些轮次是"无效轮次"（没产生新信息）？

没有这些数据，你的优化就是盲猜。我见过团队花两周做上下文压缩，结果发现瓶颈根本不在历史，而在某个工具返回了巨大的 JSON。数据先行，能帮你把力气花在刀刃上。

5.3 缓存失效是最大的隐形坑

最后再强调一次缓存。缓存能省 Token，但缓存失效处理不好会引入极难排查的 bug。几个实操建议：

• 缓存 key 要包含所有影响结果的输入，别漏字段。
• 给缓存设 TTL，尤其是涉及外部数据的。
• 缓存命中时，在上下文里明确标注"这是缓存结果，可能不是最新"，让模型自己判断要不要重新查。
• 上线前专门测一遍"数据变更后缓存是否正确失效"。

我在一个项目里就因为缓存 key 漏了一个筛选参数，导致不同用户看到了彼此的数据，排查了大半天。这种坑，一次就够记一辈子。

Agent 的 Token 优化这件事，说到底是在"信息完整性"和"计算成本"之间找平衡。SoL-Pi 给的是一套结构化的思路，Harness 是你落地这套思路的地方，而真正省下多少，取决于你对任务本身的理解有多深——哪些信息是决策必需的，哪些只是过程噪音。把这个问题想清楚了，省 Token 就是水到渠成的事。