-

前言

缸中之脑

相信大家都听过这么一个词”缸中之脑”，这个词用来形容LLM再合适不过。

LLM被称为”缸中之脑”，并不仅仅是使用LLM的感受，从模型诞生和使用的transformer等原理也是一样。

所以LLM被定位成”缸中之脑”，未来N年内，这个定位都不会变。

既然这个定位不会变，所以业内基于这个定位去发展产品能力，就非常合理了。

可以做什么？

如果让我们对LLM新增能力，可能比较难解释。但如果对”缸中之脑”这么一个具体的事务新增能力，就比较好理解了。

可以新增哪些能力呢？

  1. 加上眼睛

“缸中之脑”没有视觉能力，所以我们要给它新增视觉能力，比如browser-use。

  1. 加上信息检索能力

“缸中之脑”是静态的，虽然聪明，但它自己不会产生训练数据，所以我们要给它源源不断新增数据，或者让它自己去和外界产生链接，比如MCP、function call、GoogleSearch能力。

  1. 对齐人脑使用方法

“缸中之脑”和人的大脑一样，它是有缓存上限的，人的大脑接受信息太多后，会先用笔记的方式把信息记录下来，所以我们也要给”缸中之脑”开辟一个它的空间，让它可以把觉得重要的信息记录下来，让大脑集中在思考问题上。

  1. 加上双手

“缸中之脑”没有手，它的产出方式只有文本，所以要给它装上手，允许它像人一样调用不同的工具，比如：PythonExecute。

其实上面4个能力，也是Manus的核心能力，也就是通用Agent的能力，但大家有没有发现，还缺了一个环节：

“缸中之脑”目前还不能「操作物理世界」，涉及到物理操作坑很多，后续有结论再同步，我们本节先聚焦通用Agent。

Manus

browser-use

Manus的核心能力是基于 browser-use 的，这是一个开源的让AI访问网站的框架。

如果你使用过Manus，在Manus开辟的虚拟环境里肯定见到过类似上图的工作流程，这背后就是 browser-use 在work。

browser-use 的实现很巧妙，但原理不复杂，接下来我们不废话，直接拆 browser-use 项目看源码。

元素染色

browser-use 是对页面上每一个可互动的元素都进行了彩色标注，也就是截图我们看到的那样，核心实现就是项目中 highlightElement ，这部分没什么亮点，纯染色。

它的创新核心是把按钮等dom节点元素拆成文本，帮助ai更好理解网页上有哪些选项，然后自主做出决策。

这部分的代码在： browser_use -> dom -> buildDomTree.js

这部分代码太长了，就不贴了，感兴趣大家可以自己看下代码。

简单来说，它通过递归的方式，对网页上的元素进行深度优先遍历，并将遍历的结果以字符串的行为告知LLM。

本机配置 browser-use 相比使用Manus是有一些好处的，比如你可以配置使用自己的chrome浏览器，这样就可以使用上cookie的能力，访问更机密的信息。（注意要保证基座LLM的私有化，不然信息就泄露了。）

prompt

提示词在工程的 prompts.py 文件里，我们抽出来直接看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
		planner_prompt_text = """
You are a planning agent that helps break down tasks into smaller steps and reason about the current state.
Your role is to:
1. Analyze the current state and history
2. Evaluate progress towards the ultimate goal
3. Identify potential challenges or roadblocks
4. Suggest the next high-level steps to take

Inside your messages, there will be AI messages from different agents with different formats.

Your output format should be always a JSON object with the following fields:
{{
    "state_analysis": "Brief analysis of the current state and what has been done so far",
    "progress_evaluation": "Evaluation of progress towards the ultimate goal (as percentage and description)",
    "challenges": "List any potential challenges or roadblocks",
    "next_steps": "List 2-3 concrete next steps to take",
    "reasoning": "Explain your reasoning for the suggested next steps"
}}

Ignore the other AI messages output structures.

Keep your responses concise and focused on actionable insights.
"""

这个prompt对理解下一步「规划器」至关重要。

规划器

这部分我们重点要一下 service.py 这个文件，执行流程分为 规划器 、解析器 和 执行器。

流程是：

规划器 planner_llm 会将用户的任务进行步骤解析。

解析器 get_next_action 会不断循环解析步骤。

执行器 multi_act 接收 get_next_action 返回的要执行的任务。

function call

Manus 作为集各家项目大成的产品，function call是肯定要上的能力，但因为 Manus 也没开源，所以我们这里只介绍一下 function call的原理。

function call并不是LLM直接去调用提供的外界api，而且由 server 去承担 api 和 llm 的中间层功能。

直接上一份标准 function call 代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
def process_user_query(self, query):

	# 把用户的query存到history里，等后续调用function call之后，要把function call的结果连带query一起发给LLM
	self.history.append({"role" : "user", "content" : query})

	# 先初步用query调用LLM，让LLM决定是否要调用function call
	first_moedel_response = self.call_model()

	# 把LLM返回的内容抽出来
	first_model_message = first_model_response["choices"][0]["message"]
	# 把LLM返回的内容也抽到history里
	self.history.append(first_model_message)

	# 检查模型是否需要调用工具
	if "tool_calls" in first_model_message and first_model_message["tool_calls"] :
		tool_call = [first_model_message["tool_calls"][0]
		tool_name = tool_call["function"]["name"]
		tool_args = json.loads(tool_call["function"]["arguments"])

		# 执行function call
		result = self.execute_tool(tool_name, tool_args)

		self.history.append({
			"role" : "tool",
			"tool_call_id" : tool_call["id"],
			"name" : tool_name,
			"content" : result
		})

	else : 
		# 不需要使用模型，直接return
		return {
			"final_response" : first_model_message["content"]
		}

说到这里，不贴一张完整Manus框架就不合适了：

思考

关于Manus工程复杂度的思考

当然了，我们如果看成果，会发现 browser-use 的实现理念并不复杂。

但如果大家有写过dom解析或者App自动化XCTest的方案，会发现idea并不重要，

这类工作的难点是在于工程完备性，简单来说就是脏活累活，dom解析和XCTest解析的本质，

在于尝试用一套第三方视角在看不到项目源码的前提下去解析网页，

按我开发XCTest的经验，经常会出现某些节点无法解析，脚本点击运行事件冲突等问题，这是 browser-use 解决很好的地方。

与此同时，browser-use 这个项目仍在快速迭代中，其核心模块 service.py 在近一个月已经发生了比较大的重构。。。

关于对LLM落地产品方向的思考

很久之前我使用XCTest通过VoiceOver能力做过第三方视角操作的能力，但这里还不够智能。

如果使用XCTest这套方案，加上LLM的智能基座，我实现美团自动点咖啡、指定回复微信某个人的消息，就是手拿把掐的事情了。

能做的太多，先写到这里，感谢阅读。