开源顾问神器advisor-middleware:Haiku+Opus混合推理降本90%


这是一个叫advisor-middleware的开源项目是Anthropic的Advisor Strategy的开源实现,这个东西干了一件特别聪明的事:它把Anthropic公司的顾问策略完完整整复制到LangChain的DeepAgents框架里。

advisor-middleware完美复刻了 Anthropic 的 Advisor Strategy,可以直接插入 LangChain 的 DeepAgents。它的核心思路是把一个便宜、速度快的执行器(Haiku)和一个强大的顾问模型(Opus)搭配起来;执行器处理常规任务;顾问只在关键决策时介入,让整个流程既高效又经济。

  1. 策略Strategy将快速、低成本的执行器模型与功能强大的顾问模型相结合;
  2. 执行器负责端到端运行;
  3. Advisor顾问仅在关键决策时才征求意见。

三者结合的结果:以更低的成本实现更高的性能。

传统的子代理模式通常需要大规模的任务分解、频繁调用昂贵模型,还要维护复杂的工作池和调度逻辑。而 Advisor Strategy 只在必要时调用高成本模型,通过 max_uses 控制成本,简化流程同时提高可靠性。这种策略对于开发者而言,简直是“省钱又省心”的利器。


advisor-middleware解决什么问题?

传统 vs advisor-middleware:

  • 传统子代理模式(大型协调器拆解任务)→使用advisor-middleware 顾问策略(小型执行器从头跑到尾)
  • 传统每次都要调用昂贵模型 → advisor-middleware只在必要时才咨询昂贵模型
  • 传统需要工作线程池+协调开销 → advisor-middleware零协调——只是一个工具调用
  • 传统成本难以预测 → advisor-middleware用“最大调用次数”这个护栏来封顶顾问的支出

advisor-middleware就是让一个便宜、速度飞快的模型当跑腿执行器,再让一个超强、超贵的模型当军师顾问。跑腿小弟处理那些日常杂活,军师只在遇到重大决策时站出来说一句“你这么干会死,听我的”。这样整个流程既跑得飞快,又不会把钱包烧穿。

传统那种子代理模式特别坑。它动不动就把一个大任务拆成几十个小任务,每个小任务都要调用一次那种贵得离谱的模型。你还要维护一堆复杂的工作池和调度逻辑,写代码写到怀疑人生。顾问策略完全反过来:平时小弟干活,只有小弟搞不定或者需要跨文件逻辑推理的时候,军师才介入一次。通过一个叫max_uses的参数,你就能死死卡住军师的出场次数,成本控制得明明白白。对于开发者来说,这简直就是“少花钱多办事”的终极答案。

双模式运行原理:Native模式白嫖API,Fallback模式随意混搭任何模型

advisor-middleware支持两种运行模式,分别叫Native模式和Fallback模式。

Native模式专门为Anthropic家的执行器设计。它直接往Anthropic的server-side工具规范里注入调用信息,整个过程零额外轮询。什么意思呢?就是小弟跑腿的时候,系统根本不需要反复问“军师要不要看一眼”,没有任何多余开销。这就像你雇了一个快递员,他认识所有路,从来不用停下来看地图,效率高到离谱。

Fallback模式就更有意思了。它可以适配任何执行器和任何顾问模型的组合,不管你用OpenAI的GPT、Google的Gemini还是本地跑的小模型。Fallback模式通过直接LLM调用完成顾问咨询,也就是说军师和小弟不需要认识同一个老板,完全跨公司协作。

这种设计的好处太明显了:你手里有什么模型就能用什么模型,自由度极高。Native模式自动识别Anthropic执行器然后调用内部API,Fallback模式让你随便选顾问模型和上下文策略。无论你用哪种执行器,都能享受到军师级别的决策支持。

也就是说,这种设计的好处是,无论你使用哪种执行器,都能享受到顾问模型的决策支持。Native 模式自动识别 Anthropic 执行器并调用内部 API,而 Fallback 模式则允许开发者自由选择顾问模型和上下文策略,灵活性极高。

三步升级你的DeepAgent:安装到运行不超五分钟

安装这个中间件就一行命令。你打开终端,输入pip install advisor-middleware,回车,搞定。如果你想尝鲜最新源码,也可以执行pip install git加上那个GitHub地址。整个过程不会超过三十秒,比泡一碗方便面还快。

安装完之后配置超级简单。

你先从deepagents包导入create_deep_agent函数,再从advisor_middleware导入AdvisorMiddleware类。
然后创建一个中间件对象,参数里指定顾问模型为claude-opus-4-6。
接着调用create_deep_agent,把执行器模型设成anthropic:claude-sonnet-4-6,系统提示词写成“你是一个资深软件工程师”,再把backend和中间件列表传进去。

就这么三步,你的DeepAgent就升级完成了。Sonnet负责跑腿执行任务,Opus当军师提供咨询,中间件自动识别Anthropic并使用Native API,完全不需要你额外配置。如果你想跨提供商使用,稍微改一下AdvisorConfig就行。

成本控制配置:max_uses把军师出场次数锁得死死的

AdvisorConfig这个配置类给你提供了四个超实用的参数。

第一个是max_uses_per_turn,它限制每一轮任务中军师最多能被叫出来几次。
第二个是max_uses_per_session,它控制整个对话会话期间军师的总出场次数上限。
第三个是prefer_native,一个布尔值,问你是不是优先使用Native模式。
第四个是context,用来管理上下文,包括系统提示、工具结果和消息长度限制。

通过合理设置这些参数,你可以把顾问模型的调用成本控制得死死的,同时保证关键任务依然能得到最优指导。

举个例子,你设置每轮最多叫两次军师,整个会话最多叫十次,再把上下文消息数量限制在十条以内,并且不让工具结果混进上下文。这种配置不仅节省计算资源,还避免了上下文膨胀。军师每次看到的信息都精简又精准,给出的建议也就更高效。你不用担心军师被一堆废话干扰,也不用担心它胡乱消耗你的API额度。

实战效果验证:Haiku加Opus组合让测试通过率从11/12飙到12/12

我们做了一个真实的调试任务来验证这个中间件的效果。任务背景是一个由四个文件组成的异步任务队列系统,里面存在一个交互错误。我们先用Haiku模型单独执行,让这个小弟自己修。结果Haiku反复修改了好多次,依然没法彻底修复那个bug。每次改完跑测试,总是有一个用例过不去,小弟急得团团转但就是找不到问题根源。

然后我们把Opus顾问加进来。

神奇的事情发生了:军师只出来一次,看了一眼四个文件之间的关系,立刻指出问题出在信号量释放和circuit breaker的交互逻辑上。

Opus给出了精准的修复方案,小弟照着执行一次,所有bug全部修复。

测试通过率从原来的11/12直接提升到12/12,文件写入次数从7次降到3次,总耗时从210.7秒猛降到90.3秒。

这就是军师的价值:跨文件逻辑推理、识别每个丢弃连接的信号量释放、正确判断熔断器状态、优化任务重排策略。一次精准咨询,避免了小弟反复试错浪费时间和金钱。

内省与追踪:军师每句话你都能看到用了多少token

使用AdvisorMiddleware之后,你可以轻松追踪顾问模型的所有调用情况。代码里直接写print函数,加上mw.get_total_uses就能看到军师总共被叫了多少次。再写一个print加上mw.get_total_advisor_tokens,你就能知道军师消耗了多少token。这两个数字一出来,成本就清清楚楚。

你还可以遍历mw.get_events返回的所有事件。每个事件里包含轮次编号、采用的策略、顾问消耗的token数、军师看到的问题摘要、军师给出的建议摘要。把这些信息打印出来,你就能复盘每一次军师出场的全过程。

通过这些追踪指标,开发者能够量化顾问的真实贡献,发现哪些调用是必要的、哪些是浪费的,然后进一步优化调用策略。你可以大胆地把max_uses_per_turn从2降到1,或者把某些类型的任务直接从顾问流程里踢出去,省钱省到骨头里。

文件结构:七个文件各司其职,想改哪里改哪里


advisor_middleware的目录结构非常清晰。

advisor_middleware/
├── <strong>init</strong>.py        # 公共 API
├── middleware.py      # 核心中间件:dual-mode wrap_model_call
├── config.py          # AdvisorConfig + ContextCurationConfig 数据类
├── state.py           # AdvisorState + AdvisorEvent TypedDicts
├── prompts.py         # 执行器 + 顾问系统提示
├── providers.py       # 提供者检测,Native/Fallback 调用
└── py.typed           # PEP 561 类型标记


init.py负责暴露公共API,你只需要从这里导入AdvisorMiddleware和AdvisorConfig。
middleware.py是核心文件,里面实现了双模式的wrap_model_call,也就是拦截模型调用然后决定让小弟干还是让军师干。
config.py定义了两个数据类,AdvisorConfig和ContextCurationConfig,所有配置参数都在这。
state.py定义了AdvisorState和AdvisorEvent这两个TypedDict,用来规范状态和事件的数据结构。
prompts.py存放执行器和顾问的系统提示词,你可以随便改。
providers.py负责提供者检测,判断当前应该用Native模式还是Fallback模式调用。

最后还有一个py.typed文件,用来满足PEP 561的类型标记要求。

这种模块划分非常合理,方便你扩展和维护。如果你想改进顾问策略,直接改prompts.py或者providers.py。如果你想增加上下文管理功能,改config.py和state.py就行。如果你想调试执行器,看middleware.py就够了。任何一个开发者拿到这个代码库,都能在十分钟内搞清楚每一块是干嘛的,然后迅速上手修改。

总结

advisor-middleware 将执行器和顾问模型有机结合,实现低成本高效率的智能代理执行。Native 与 Fallback 双模式、灵活配置、清晰追踪和模块化架构,使其成为 DeepAgents 开发者的必备利器。无论是调试复杂系统还是跨文件任务优化,这个中间件都能显著提升性能。