最近我们刚发布了Bridgic v0.3.0b1版本,升级了长程自主性智能模块[1],并且完善了MCP集成能力[2]。今天我就来和大家介绍一下,如何组合这些底层能力来实现一些有意思的功能(具备高度自主性的),以及将自主性模块加入到Bridgic风格的编排体系中的背后的一些设计思考。
接下来的内容分四个部分:
熟悉Bridgic的朋友可能已经知道了,在Bridgic的最底层,我们使用动态拓扑来统一编排确定性的模块和自主性的模块,期望将各种不同的智能组件纳入到一个系统里面来无缝工作。
在Bridgic上一个版本,其实已经有了一个基于ReAct的自主性模块(具体实现是ReActAutoma类[3])。但是,对于执行真正长程的自主性任务来说,ReActAutoma存在一个问题:随着时间的推移,调用工具的结果以ToolMessage的形式不断追加进上下文,造成「上下文爆炸」和「目标漂移」。
因此,我们对自主性模块进行了重大升级,使它更适合执行长程的自主性任务。这个新的模块实现,名字叫ReCentAutoma[1]。它是一个增强的ReAct (Resoning and Acting) loop,实现了一种称为ReCENT (Recursive Compressed Episodic Node Tree) 的记忆压缩算法。具体来说:
ReCentAutoma显式提供了goal参数和guidance参数,允许开发者指明任务目标和任务指导信息。这些信息不会被ReCENT算法压缩,保证智能体长时间运行时能够维持目标。值得一提的是,ReCentAutoma的内部实现也是基于Bridgic底层的动态拓扑来进行编排的。因此,ReCentAutoma也能够享受到Bridgic框架底层提供的可观测性集成能力和human-in-the-loop的中断、恢复等能力。换句话说,在Bridgic的世界中,动态拓扑既用于编排确定性模块和自主性模块,把这两种类型的模块融合在一个系统中,也同时用于编排自主性模块的内部结构。底层是统一的。
另外,为了让这个自主性模块能够与市面上现有的工具更轻松地对接,Bridgic这个版本对MCP集成的能力也进行了完善(引入了ToolSetBuilder)。至此,Bridgic的「工具架构」已经自成体系,可以用下面的图来表达(点击看大图):
以上架构遵循了Bridgic一贯的协调统一的设计风格:
GraphAutoma子类。「原材料」的种类可以根据需要扩展(这是Bridgic对外提供的用于扩展工具的地方)。ToolSpec。它表达了一个工具全方位的信息(描述信息+执行信息),对应有不同的子类实现。ToolSpec经过API to_tool()转换成Tool这个类,表达成了被LLM能够理解的工具形式。这种形式的表达用于与LLM交互,完成工具调用。ToolSpec经过API create_worker()转换成了Worker。Worker被动态加入到GraphAutoma中,就可以利用Bridgic动态拓扑的编排能力完成执行。GraphAutoma的子类(不管是借助@worker还是ASL声明的),又都可以成为工具的「原材料」。有了长程自主模块ReCentAutoma和MCP工具,我们就可以组合出很多自主性的智能体。下面举一个浏览器自动化的例子。一般来说,浏览器自动化的任务需要让模型理解页面内容,很容易撑爆上下文窗口,因此对于记忆的管理和压缩就非常有必要。
在这个例子中,我们选择Playwright提供的MCP工具[4]。如下,当前共有22个工具。
以下是核心代码片段(完整代码参见[5]):
playwright_connection = McpServerConnectionStdio(
name="connection-playwright-stdio",
command="npx",
args=[
"@playwright/mcp@latest",
f"--output-dir={temp_dir}",
"--viewport-size=1920x1080",
"--save-video=1920x1080",
],
request_timeout=60,
)
...
tools = playwright_connection.list_tools()
browser_agent = ReCentAutoma(
llm=llm,
tools=tools,
memory_config=ReCentMemoryConfig(
llm=llm,
max_node_size=8,
max_token_size=1024 * 32,
),
stop_condition=StopCondition(max_iteration=20, max_consecutive_no_tool_selected=1),
running_options=RunningOptions(debug=True),
)
# Use the agent to find recent gold prices on Hong Kong Gold Exchange website
result = await browser_agent.arun(
goal=(
"Find the recent gold prices on Hong Kong Gold Exchange website."
),
guidance=(
"Execute the following steps strictly sequentially; do not perform any two steps in parallel.\n"
"1. Navigate to https://hkgx.com.hk/en\n"
"2. Hover on the 'Market & Data' button to show more button options\n"
"3. Click the 'Price History' button to access the historical price page\n"
"4. As the current date is already selected, simply select the “RMB Kilo Gold” option.\n"
"5. Click the search button and have a look at the recent gold price trends\n"
"6. Close the browser and give out a summary of recent gold price trends\n"
),
)
print("Final Result:\n\n")
print(result)
# Close the connection when done
playwright_connection.close()
上述代码要完成的功能是,驱动浏览器去访问香港黄金交易所的网站,然后点击各个菜单并筛选查询条件,最后检索出最新的金价并进行总结。以下是执行效果:
下面是截取的一段中间执行过程的日志:
如果你想亲自run一下以上代码,只需要执行以下几行命令即可:
git clone https://github.com/bitsky-tech/bridgic-examples.git
cd bridgic-examples
uv run --prerelease=allow agentic/recent_browser_gold_price.py
更多例子代码请查阅bridgic-examples工程[6]。
自从Claude Code彻底出圈之后,它所推出的Skills概念也随后爆火。很多人就问了,Anthropic先是推出了MCP,后来又推出了Skills,是不是Skills会取代MCP?
我们先看下Claude Code目前的情况。
首先,在Claude Code中,Skills是提供Knowledge的,而不是用于提供工具的。如果你想在Claude Code的system tools之外,额外给它配置一些其他的工具,那么似乎还是只能依赖MCP。实际上,Skills能做的事更多,你可以在里面配置流程、编码规范、业务知识、代码示例、各种规则等等,以及对于现有工具的调用指导,你都可以在Skills中描述。但是,引入新的工具还是得通过MCP。
其次,Skills和MCP这两个机制还有一个很大不同:Skills天生提供了渐进式披露的能力,而MCP默认没有。这也是为什么有人会说,MCP会消耗大量token,甚至撑爆上下文窗口。不过,这其实跟MCP协议本身并没有直接关系。实际上,在Claude Code中,也不是所有MCP工具都会常驻上下文窗口。它有一个Tool search的技术[7]:
Tool search (enabled by default) loads MCP tools up to 10% of context and defers the rest until needed.
这跟Skills的渐进式加载机制不同,但通过search的方式去避免了对上下文窗口的过度占用。
前面我们说,在Claude Code中引入新工具还是得通过MCP,这话其实也不绝对。如果你提供的工具是可以通过Bash调用的,换句话说,是CLI形式的工具,那么是相当于可以通过Skills引入进来的。这是因为Bash这个工具是Claude Code的一个system tool,而这个Bash工具就很特殊,它可以调用其他命令行工具。
所以,真正需要对比的可能不是Skills vs. MCP,而是CLI tools vs. MCP tools。
作为一个真实的CLI tools的例子,Playwright近日就发布了一个新项目,叫playwright-cli[8],就是把浏览器工具封装成了一套CLI的形式。
那么,MCP tools如果和CLI tools比较起来,会怎么样呢?
第一个不同,可能在于,MCP tools会消耗大量的token,而CLI tools很可能会选择把大量的文本写入文件。当然了,这其实也跟MCP协议本身没有直接关系。可能只是因为,MCP毕竟是个更类似于函数调用的形式,运行结果通过函数输出返回给LLM,是更方便也自然的一个设计。
第二个不同,MCP可以比较方便地调用远程的服务,而CLI是本地命令。但这也只是形式上的区别。CLI是本地命令不假,但不代表它就不能执行远程的功能。
第三个不同,可能更贴近本质:MCP是大模型时代从头设计出来的新技术,而CLI则是存在了几十年的工具形式,几乎在计算机被发明初期就存在了。新技术自然免不了需要教会模型更好地使用它,也同时需要一大堆工程架构来支撑它;而CLI可能模型早就懂得如何使用了(碰到不懂的时候还可以用Skills来指导模型)。值得一提的是,MCP是依照软件开发范式设计出来的,而CLI则是设计给人使用的。
最后,从逻辑上看,Skills基本上是独立于工具的概念,它可以和各种形式的工具配合使用。比如:
至于说,最终是CLI tools取代MCP tools,还是反过来,或者是两种会长期共存?技术的进化是个很复杂的过程,既有路径依赖,又有跳跃式的变革,现在预测可能还为时尚早。关键是理清楚其中的关键点,作为技术管理者你就知道如何提前布局。
最后,列出一些网上公开的MCP servers。大家可以组合这些MCP工具和ReCentAutoma,尝试玩出一些新的花样。当然了,对于开发agentic自主性系统来说,今天介绍的只是非常基础的技术。对于更复杂的自主性任务,如何才能精确地控制它,会涉及到更多本质的东西。我们后面再跟大家分享。
我建了一个“Bridgic开源技术交流群”,会在群里发布项目的开发进展及计划,并讨论/分享相关技术。感兴趣加入的朋友请前往Bridgic GitHub首页README中扫描二维码,并欢迎在GitHub给个star!
💾 Bridgic:一个支持动态拓扑的AI智能体框架:
点击这里直达GitHub首页 ➜ https://github.com/bitsky-tech/bridgic
(正文完)
其它精选文章: