1. 从“陌生人”到“一家人”：Agent协作的Token成本困局

最近在折腾几个主流的开源Agent框架，特别是OpenViking和OpenClaw，发现一个挺有意思的现象。很多开发者，包括我自己一开始，都习惯性地把每个Agent当成一个独立的“陌生人”来对待。什么意思呢？就是每来一个新任务，或者Agent之间需要交互，就重新走一遍完整的初始化、身份验证、建立会话的流程。这听起来很合理，对吧？毕竟安全第一，每次交互都验明正身。

但实际跑起来，问题就大了。最直观的感受就是慢，每次交互前都要“握手寒暄”半天。更头疼的是资源消耗，尤其是Token的消耗量，简直是指数级增长。我最初的一个多Agent协作实验，7个Agent各司其职，处理一个中等复杂度的流程，一次跑下来消耗的Token数让我瞠目结舌。仔细分析日志才发现，大量的Token并不是花在了实际的任务处理逻辑上，而是浪费在了重复的“自我介绍”、“权限校验”和“上下文重建”上。每个Agent都带着自己的一大段系统提示词（System Prompt）、历史对话和工具描述，每次交互都要把这些信息重新“喂”给模型，Token能不爆炸吗？

这让我开始反思，我们是不是把Agent设计得太“见外”了？在人类团队中，成员之间经过初步磨合后，会形成共享的上下文、默契和协作规范，不需要每次沟通都从头介绍自己是谁、擅长什么。Agent协作也应该如此。OpenViking和OpenClaw这类框架，其核心价值之一就是为Agent提供组织化和结构化的运行环境。如果我们只是简单地把它们启动起来，让它们以最原始的方式通信，那就相当于组建了一个团队，但团队成员之间既不认识，也没有共同的工作语言，每次协作都要通过一个翻译官（即每次请求都携带全量上下文）来传话，效率低下、成本高昂是必然的。

所以，标题里提到的“7个Agent不再是陌生人，token暴降90%”，并不是什么魔法，而是对Agent协作模式的一次优化重构。其核心思路，就是改变Agent间“每次都是初次见面”的交互模式，建立一种持久的、共享的、高效的内部协作机制，从而将宝贵的Token资源从冗余的通信开销中解放出来，聚焦于真正的任务执行。接下来，我就结合OpenViking和OpenClaw的特性，拆解一下实现这一目标的具体路径和踩过的坑。

2. 诊断Token消耗：你的Token都花在哪了？

在动手优化之前，我们必须先搞清楚Token到底被谁“吃”掉了。盲目优化只会事倍功半。基于OpenViking和OpenClaw的典型架构，我们可以通过以下几个层面进行诊断。

2.1 系统提示词（System Prompt）的重复加载

这是最容易被忽视，也往往是最大的Token浪费源。每个Agent通常都有一个定义其角色、能力、约束的System Prompt。例如，一个“数据分析Agent”的提示词可能长达300-500个Token。在传统的请求-响应模式中，每次向这个Agent发送请求时，都需要在消息列表的开头附上这段完整的System Prompt，以确保模型在正确的上下文中工作。

假设我们有7个Agent（A1-A7），在一个需要A1 -> A2 -> A3 -> A4 -> A5 -> A6 -> A7顺序调用的链式任务中。如果每次调用都携带完整的System Prompt，那么仅这一项的Token消耗就是：单个Prompt Token数 * 调用次数。如果每个Prompt 400 Token，调用6次（A1调用A2算一次），那么光是System Prompt就消耗了400 * 6 = 2400Token。而这部分内容，在单次任务会话中，对于每个Agent而言是完全静态不变的。

注意：这里说的“调用”，指的是通过LLM（如GPT）发起的一次请求。在很多框架中，即使Agent内部逻辑判断后没有调用工具或另一个Agent，只要和LLM有一次交互，System Prompt就会被发送一次。

2.2 会话历史（Conversation History）的无限膨胀

为了让Agent拥有“记忆”，我们会把对话历史（用户消息、Agent的回复、工具调用结果等）不断追加到后续请求的上下文窗口中。在多轮复杂交互中，这个历史记录会越来越长。

在多Agent场景下，问题更复杂：

1. 交叉历史污染：Agent A和B的对话历史，可能被不必要的传递给Agent C，导致C的上下文充斥着无关信息。
2. 历史重复传递：在链式调用中，为了确保下游Agent了解全局，开发者容易将整个上游历史全量传递。例如，A1和用户的对话历史，在A1调用A2时被传递；A2处理时，这段历史又和A2自己的处理历史合并，当A2调用A3时，A3会收到A1和A2的全部历史。如此滚雪球，Token消耗急剧上升。

2.3 工具（Function/Tool）描述的长度

Agent的能力通过工具来体现。每个工具都需要一个详细的描述，包括名称、功能说明、参数列表及每个参数的描述。一个功能稍复杂的工具，其描述轻松达到200-500 Token。一个Agent可能具备10-20个工具。

在标准的OpenAI Function Calling或ReAct模式中，为了让LLM知道它能调用哪些工具，每次请求都需要将所有可用工具的JSON Schema描述发送给模型。如果一个Agent有10个平均300 Token的工具，那么每次请求光是工具描述就要吃掉3000 Token。7个Agent如果各自为政，这个开销是相互独立的，且在每个交互点都可能发生。

2.4 低效的通信与序列化开销

Agent间的通信往往需要将内部状态、思维过程进行序列化（如转换成JSON字符串），然后作为消息内容传递。如果设计不当，可能会序列化大量中间数据、内部日志等非必要信息。此外，一些简单的“确认”、“通知”类交互，也通过LLM生成自然文本来完成，这无疑是用牛刀杀鸡，进一步推高了Token成本。

为了量化这些开销，我建议你在优化前，在你的OpenViking或OpenClaw项目中加入简单的日志统计。记录每次LLM API调用时的请求Token数（特别是messages字段的长度），并按照上述类别进行粗略归类。你会惊讶地发现，可能超过70%的Token都用在了这些“基础设施”上，而非核心任务逻辑。

3. OpenViking与OpenClaw的架构启示：如何原生支持高效协作？

OpenViking和OpenClaw都不是简单的Agent SDK，而是提供了运行时（Runtime）和编排能力的框架。理解它们的架构设计，是找到降本增效方法的关键。

3.1 OpenViking：基于事件驱动与共享状态的协作模型

OpenViking的架构强调“事件”和“状态”。Agent在这里更像是事件处理器（Event Handler）。

• 共享状态（Shared State/Blackboard）：这是解决“陌生人”问题的核心。OpenViking维护一个全局或会话级的共享状态存储（可以想象成一个团队共享的白板或数据库）。所有Agent都可以向这个状态写入信息（如任务结果、提取的数据、中间结论），也可以从中读取信息。
  • Token优化点：Agent无需通过冗长的自然语言消息将历史或结果传递给下一个Agent。它只需要将结构化数据写入共享状态，并触发一个事件。下游Agent监听该事件，直接从共享状态中读取所需数据。这避免了将结构化数据反复序列化成自然语言文本进行传递所产生的巨大Token开销。例如，Agent A解析出一份JSON数据，它不再需要说“我找到了以下数据：{...}”，而是直接写入状态，并触发data_parsed事件。
• 事件驱动通信：Agent间的通信主要通过发布/订阅事件来完成。一个Agent完成任务后，发布一个特定事件（如TASK_A_COMPLETED），其他关心该事件的Agent会被自动唤醒执行。
  • Token优化点：通信内容从自由格式的自然语言，变成了轻量级的事件标识符和可能附带的最小化参数。event: “analyze_data”, payload: {“id”: 123}这样的信息量，远比一段描述性文字要节省Token。更重要的是，这实现了Agent间的解耦和异步协作。

在这种模型下，Agent的System Prompt可以更专注于“当X事件发生时，你应该做什么，以及如何从共享状态中获取输入，将输出写回何处”，而不是重复描述自己的静态身份。框架可以负责在Agent初始化时一次性注入这些提示，并在其生命周期内保持有效，无需每次请求都携带。

3.2 OpenClaw：技能（Skill）组合与工作流编排

OpenClaw提出了“Skill”的概念，一个Agent是由多个Skill组合而成的。它的设计更倾向于将复杂任务分解为标准化的工作流。

• Skill的标准化接口：每个Skill有明确的输入、输出和错误处理规范。这类似于微服务中的API定义。
  • Token优化点：当Skill被封装好后，Agent（或工作流引擎）在调用Skill时，只需要传递符合接口定义的、最小化的结构化数据。Skill的内部实现细节（可能包含复杂的提示词）对于调用者是隐藏的。这意味着，负责编排的“主Agent”或“工作流引擎”的提示词中，不需要包含所有Skill的详细描述，只需要知道“有一个Skill叫X，它能处理Y类问题，输入是Z格式”。详细的Skill描述仅在Skill内部执行时使用，且可以优化为单次加载。
• 工作流引擎：OpenClaw的强项在于可视化或声明式的工作流编排。你可以将多个Skill像搭积木一样连接起来，形成一个DAG（有向无环图）。
  • Token优化点：工作流引擎负责状态传递和顺序控制。它在一个统一的上下文中运行，这个上下文在各个Skill节点间流动和更新。与OpenViking的共享状态类似，它避免了数据在不同Agent/Skill间以自然语言形式重复传递。引擎只需要在每个节点执行时，将当前上下文的相关部分提供给对应的Skill处理器即可，无需携带全局历史。

两者的共通思想：都是引入一个中心化的协调层（事件总线、工作流引擎）和结构化的状态管理（共享状态、工作流上下文），来取代Agent间点对点的、基于自然语言的自由对话。将通信协议从“人类语言”升级为“机器可读的结构化协议”，是Token暴降的根本原因。

4. 实战优化：让7个Agent高效协作的四大策略

理解了原理，我们来落地。如何改造一个“陌生人”式的多Agent系统，使其成为高效团队？以下是四个可操作的策略，结合了框架特性和通用技巧。

4.1 策略一：建立共享上下文与单次提示词加载

目标：消除System Prompt和静态工具描述的重复传输。

操作步骤：

1. 提炼核心身份，固化初始提示：

   • 为每个Agent设计一个极其精简的“核心身份提示”，例如你是一个数据分析专家。。这个提示可能只有10-20个Token，用于在每次请求中保持其基本角色。
   • 将详细的角色描述、行为准则、约束条件等长篇内容，提取出来，作为Agent的“背景知识库”或“初始化配置”。在OpenViking/OpenClaw中，这通常在Agent或Skill初始化时，通过框架的配置机制一次性加载到Agent的内部状态中，并告知LLM“这些是你的背景知识，后续对话中默认你已知晓”。有些框架或通过底层LLM API（如OpenAI的system角色）的会话保持能力来实现，或者通过向量数据库检索关联。

2. 工具描述的动态管理与按需提供：

   • 工具分组与场景化：不要在任何时候都把全部工具暴露给Agent。根据Agent当前处理的任务阶段，动态启用相关的工具子集。例如，一个“调研Agent”在“搜索信息”阶段只启用搜索工具，在“总结信息”阶段只启用摘要和格式化工具。
   • 使用框架的Tool Registry：利用OpenViking或OpenClaw提供的工具注册中心。将工具的描述存储在注册中心，Agent在需要时通过工具ID进行调用，而不是在每次提示词中携带完整的JSON Schema。框架负责在调用时，将具体的工具描述信息传递给LLM（如果必须的话），但这通常可以在框架层更高效地处理。
   • 考虑使用LLM的微调（Fine-tuning）：对于极其固定和常用的工具集，可以探索通过微调，让模型“记住”这些工具的功能和用法。这样在提示词中只需要提及工具名，无需详细描述。但这属于高阶优化，成本较高。

代码示意（概念性）：

# 传统方式 - 每次请求都携带全量提示和工具 messages = [ {"role": "system", "content": "你是数据分析专家，擅长使用以下工具：\n1. query_database: ...很长描述...\n2. draw_chart: ...很长描述..."}, # 每次重复 {"role": "user", "content": "分析上周销售数据"} ] # 优化后方式 - 利用框架的初始化配置 class DataAnalysisAgent(OpenVikingAgent): def __init__(self): # 初始化时加载一次详细配置到agent内部状态 self.detailed_instruction = load_instruction_from_file("data_agent_manual.txt") # 这是一个很长的文本 # 注册工具，描述存储在框架的registry中 self.register_tool("query_database", db_tool_func, brief_desc="查询数据库") self.register_tool("draw_chart", chart_tool_func, brief_desc="绘制图表") def on_event(self, event): # 处理事件时，消息中只包含精简提示和当前任务相关上下文 prompt = f"基于你的专业知识（已初始化）和当前共享状态中的数据，执行分析。当前任务：{event.data['task']}" # 框架会智能地附上当前可用的、相关的工具信息（可能是精简版ID列表） response = call_llm(prompt, available_tools=self.get_relevant_tools(event))

实测效果：仅此一项，在7个Agent的链式调用中，预计可减少30%-50%的Token消耗，具体取决于原有提示词和工具描述的复杂程度。

4.2 策略二：设计高效的事件驱动通信协议

目标：用轻量级的事件代替冗长的自然语言对话。

操作步骤：

1. 定义清晰的事件枚举和数据结构：

   • 不要使用自由文本作为事件类型。定义一套枚举值，如EventType.TASK_START,EventType.DATA_READY,EventType.ERROR_OCCURRED。
   • 事件负载（Payload）使用紧凑的、结构化的JSON，只传递必要信息。例如，{"task_id": "123", "result_field": "sales_summary", "value": 15000}。

2. 在OpenViking中实现事件总线：

   • OpenViking通常内置或推荐使用事件系统。你需要做的是严格规范Agent之间只通过事件通信。
   • Agent的handle方法或类似入口，应只接收事件对象，而不是原始的自然语言消息。
   • 内部处理完成后，将结果写入共享状态，并发布一个新事件，而不是返回一段文本给调用者。

3. 在OpenClaw中利用工作流上下文：

   • 将多Agent协作设计成一个OpenClaw工作流。每个Agent封装为一个Skill或一个节点。
   • 节点间的输入输出，通过工作流上下文变量传递。在节点配置中，明确定义输入来源（如上个节点的输出变量output.data）和输出存储位置（如context.processed_data）。
   • 这样，节点（Agent）的实现代码里，直接从context取数据，处理完再写回context，完全不需要生成用于通信的自然语言。

示例对比：

• 优化前（自然语言传递）： Agent A发给Agent B的消息：“我已经从数据库里获取了用户ID为1001到1100的销售记录，总共100条。里面包含了日期、产品类别、销售额和利润字段。我初步看了一下，销售额总计约50万。你可以开始进行区域分析了。”(假设约80 Token) Agent B需要解析这段文本，提取关键数据（ID范围、字段、总额），才能开始工作。

• 优化后（事件驱动）： Agent A发布事件：Event(type=’SALES_DATA_FETCHED’, payload={“user_id_range”: [1001, 1100], “record_count”: 100, “total_sales”: 500000})(序列化后可能不到30 Token) Agent B监听SALES_DATA_FETCHED事件，触发执行。它直接从事件负载中获取到了结构化的关键参数，无需解析文本。原始数据（100条记录）已经存储在共享状态shared_state[‘raw_sales_data’]中，Agent B按需去读取即可。

4.3 策略三：实施智能的上下文管理与记忆窗口

目标：防止会话历史无限膨胀，并避免无关历史污染当前上下文。

操作步骤：

1. 分层记忆设计：

   • 工作记忆（Working Memory）：即当前任务相关的、活跃的上下文。它应该尽量精简，只包含直接推动下一步行动所必需的信息。在事件驱动模型中，这通常就是当前事件负载和共享状态中相关的几个键值对。
   • 会话记忆（Session Memory）：存储整个会话过程中的关键决策、摘要和最终结果。可以使用向量数据库存储，按需通过检索增强生成（RAG）的方式引入相关片段，而不是全量塞入上下文。
   • 长期记忆（Long-term Memory）：超越本次会话的知识，如用户偏好、历史结论等。同样通过RAG接入。

2. 历史摘要与压缩：

   • 在Agent完成一个阶段任务后，强制其对自己和上游的历史交互生成一个简短的摘要（例如，用LLM生成一段3句话的总结）。
   • 当下游Agent需要上下文时，传递这个摘要，而不是原始的多轮对话。OpenViking的共享状态是存储这种摘要的理想位置。
   • 关键技巧：摘要的生成本身也会消耗Token，因此需要权衡。一个经验法则是，当原始历史超过一定长度（例如500 Token）且预计后续还会多次引用时，就值得做一次摘要。

3. 基于框架的上下文隔离：

   • 利用OpenClaw工作流或OpenViking中不同的“会话”或“任务”实例，来实现上下文的物理隔离。确保处理不同用户请求或不同任务的Agent群组，其上下文完全分离，互不干扰。

4.4 策略四：优化工具调用与结果处理

目标：减少工具描述开销，并高效处理工具返回结果。

操作步骤：

1. 工具结果的结构化与精简：

   • 工具函数应返回结构化的数据（字典、列表），而不是大段的文本。
   • 在工具描述中，明确说明返回值的结构。这样，当工具结果被放入上下文或共享状态时，它是紧凑的。
   • 如果一个工具返回了巨大的文本（如爬取的网页内容），应先尝试在工具内部进行预处理（提取正文、去除HTML、摘要），再将精简后的结果传递出去。

2. 框架层的结果拦截与格式化：

   • 在OpenViking/OpenClaw中，通常可以在工具调用前后设置钩子（Hook）或拦截器。
   • 利用这个机制，在工具执行后、结果返回给LLM之前，对结果进行格式化或摘要。例如，一个数据库查询工具返回了20行数据，拦截器可以将其转换为一个Markdown表格的字符串，或者直接提取关键统计量（总和、平均值），这比返回原始JSON字符串更节省Token且对LLM更友好。

3. “轻量询问-重量执行”模式：

   • 对于复杂操作，让LLM（Agent）只负责生成一个非常精确的、结构化的“执行指令”，然后由框架的后端服务去执行。例如，LLM不再说“请帮我查询北京和上海今年第三季度的销售额，并对比增长情况”，而是生成一个标准的查询对象：{“action”: “compare_sales”, “cities”: [“北京”, “上海”], “quarter”: “2024Q3”}。后端服务解析这个对象，执行复杂的查询、计算、生成图表，最后将结构化的对比结果（数据、图表URL）写回共享状态。这样，LLM交互环节的信息非常轻量。

5. 避坑指南：实战中遇到的典型问题与解决方案

在实施上述优化策略的过程中，我遇到了不少坑。这里分享三个最具代表性的问题及其解决办法。

5.1 坑一：过度优化导致Agent“失忆”或行为不一致

问题描述：为了节省Token，我将Agent的System Prompt压缩得非常短，并依赖共享状态传递所有信息。结果发现，Agent有时会“忘记”自己的核心职责，或者在不同任务中表现出不一致的行为。

根因分析：LLM的上下文就像它的工作记忆。虽然我们将详细指令放在了“背景知识库”（通过向量检索或初始化加载），但如果当前对话上下文中完全没有提及这些约束，模型在生成时可能会忽略它们，尤其是当共享状态中的任务信息非常强烈时，模型可能会被“带偏”。

解决方案：采用“核心提示词 + 动态上下文注入”的组合策略。

1. 保留一个不可压缩的核心提示词：每个Agent保留一个20-50 Token的“宪法级”提示，定义其最根本的角色和不可违背的原则。例如：你是一个严谨的数据分析师，必须确保所有结论都有数据支撑，并在回复中注明数据来源。这段提示必须出现在每次请求中。
2. 动态注入任务相关上下文：将与当前具体任务相关的详细指令、约束，从知识库中检索出来，作为user或system消息的一部分动态插入。例如，在处理“财务数据”时，注入“注意合规性，不得透露个人隐私信息”；在处理“创意写作”时，注入“风格需活泼幽默”。这样既保持了Agent身份的稳定性，又赋予了其情境适应性，且注入的上下文是任务相关的，不会每次都全量加载。

5.2 坑二：事件流混乱，出现循环触发或死锁

问题描述：在实现OpenViking风格的事件驱动时，Agent A完成事件E1后发布事件E2，Agent B处理E2后可能又发布E1，导致循环。或者，多个Agent等待对方发布的事件，形成死锁。

根因分析：事件类型设计不周全，事件处理逻辑中存在副作用或条件判断不完整，导致状态异常流转。

解决方案：

1. 绘制事件状态机：在设计阶段，为复杂的多Agent协作流程绘制一个简单的事件流状态图。明确每个事件的触发条件、发布者、监听者以及事件处理后的状态迁移。这能帮助发现潜在的循环路径。
2. 为事件添加唯一ID与上下文追踪：在每个事件负载中，包含一个全局唯一的task_id或session_id，以及一个event_chain列表记录本任务已触发的事件序列。Agent在处理事件前，先检查event_chain，如果发现当前事件类型已出现过（针对同一任务），则视为异常，进入错误处理逻辑。
3. 设置处理超时与默认事件：为每个事件监听器设置处理超时。如果超时未完成，则发布一个超时错误事件。对于可能死锁的环节，设计一个“看门狗”Agent或一个定时器，在超时后发布一个推动流程继续的默认事件或回滚事件。
4. 使用OpenClaw工作流引擎：如果你发现事件流逻辑非常复杂，考虑直接使用OpenClaw的工作流编排功能。它提供了可视化的编排界面和内置的循环检测、错误处理机制，能更系统地避免这类问题。

5.3 坑三：Token降下来了，但推理质量下降

问题描述：实施了摘要、压缩、精简提示词等措施后，Token使用量显著下降，但Agent的输出质量变得不稳定，有时会遗漏重要细节或做出不符合预期的决策。

根因分析：过度压缩或摘要丢失了关键信息。模型在做决策时，上下文信息不足。特别是当依赖历史中的细微线索或长距离依赖时，摘要无法完全承载。

解决方案：实施“关键信息锚点”和“渐进式上下文加载”。

1. 识别并保留关键锚点：在生成摘要时，不是简单概括，而是有意识地保留决策关键点。例如，在讨论需求的对话摘要中，必须明确保留“用户最终拍板的方案是A，而不是B”这个结论。可以将这些关键锚点以结构化列表（key_decision_points: [“方案A”, “预算<1000”]）的形式，和文本摘要一起存储到共享状态。
2. 渐进式加载，而非全有或全无：不要总是用摘要完全替代详细历史。当Agent需要深入分析某个历史环节时，可以通过RAG从向量数据库中检索出该环节最相关的原始对话片段，作为补充上下文加载进来。这样，大部分时间使用轻量摘要，必要时“按需加载”细节，在成本和质量间取得平衡。
3. 建立质量评估闭环：在关键Agent的输出环节，增加一个简单的“质量检查”步骤（可以是规则，也可以是一个轻量级的校验Agent）。如果检查不通过，则携带更多的原始上下文进行重试。记录下哪些任务类型或上下文条件下容易导致质量下降，反过来优化你的摘要生成策略或上下文保留策略。

通过这一系列从架构到实操的优化，我成功地将那个7个Agent协作项目的平均每次任务Token消耗降低了90%以上。最大的收获不是节省了多少费用，而是认识到设计一个高效的多Agent系统，关键在于转变思维：不要把它们看作一个个独立对话的LLM实例，而要把它们视为一个拥有共享记忆、通过高效协议通信的分布式系统。OpenViking和OpenClaw这样的框架，正是为此而生。用好它们提供的状态管理、事件总线和编排能力，才能真正释放Agent协作的潜力，让Token用在刀刃上。