最近这两年，AI 智能体（Agent）的主战场一直在云端。Dify、Coze、LangChain 这些平台把 Agent 的开发门槛压得很低，你只需要拖几个节点，配上模型密钥，一个能查天气、订机票、读文档的机器人很快就能跑起来。但如果你真的把一个智能体放到自己日常使用的电脑上，会发现情况完全变了——它不是接口调不通的问题，而是模型、权限、上下文、工具调用全部叠在本地环境里，每一步都比云端复杂一个数量级。
这正是 Perplexity 发布便携电脑智能体研究时最值得关注的地方。它把智能体从“云端的 API 服务”拉回到了“你手边的机器”。这件事如果做成了，意味着以后打开电脑，不再是“人找功能”，而是“智能体理解你在干什么，然后替你执行”。对开发者来说，这不是一个可以围观完就划走的热点，而是智能体开发范式的又一次切换。
这篇文章我会分几层来拆：先讲清楚设备端智能体和云端智能体的本质区别；再分析 Perplexity 这项研究释放出的信号；然后落到能操作的部分，带你用 Dify 这类平台搭建一个最小可用的智能体工作流，并用 Python、Java、curl 三种方式完成接口调用；最后给出常见问题排查和工程化建议。读完你不只能看懂趋势，还能立刻动手做一次端侧智能体的最小验证。
1. 为什么“便携电脑智能体”值得单独研究
过去做智能体，本质上是在做“云端编排”。用户提问，Agent 把请求发给大模型，模型生成工具调用，Agent 再调天气 API、数据库、企业知识库，最后把结果拼装返回。这套链路是通的，但它有一个很强的隐含假设：所有工具和服务都是可以从云端访问的。
可是真实办公场景并不是这样。
你的资料在本地硬盘，你的代码在本地仓库，你的企业系统在内网，你的浏览器登录着公司账号。如果要让智能体帮你整理一份本地的项目文档，然后提炼摘要，再顺手生成一页 PPT，这个流程在云端根本跑不起来。云端的 Agent 没有你本地文件的访问权限，就算给了权限，大文件上传下载也会让响应慢到让人失去耐心。
所以便携电脑智能体的核心命题是：把模型的推理能力、工具调用能力，和本地操作系统的文件系统、应用进程、剪贴板、浏览器交互能力整合到一起。它不再是单纯“回答问题”，而是真正意义上“帮你操作电脑”。
这个概念并不新，RPA（机器人流程自动化）做了很多年。但 RPA 靠的是人工录制固定流程，规则一变就崩。新一代设备智能体靠的是模型对界面的理解和对用户意图的推理，可以处理非结构化指令。比如你跟它说“帮我把最近三天项目文档里的 todos 整理成表格”，它不需要别人预先录好一个“扫描文件夹”的流程，而是自己分析文档结构、提取关键信息、生成输出表格。
从技术栈来看，设备端智能体相比云端智能体，至少多出三层挑战：
第一层是意图识别，但偏向“操作型意图”，比如打开、读取、修改、发送。第二层是工具边界，智能体必须感知哪些本地操作是允许的，哪些是被权限限制的。第三层是执行验证，云端的 Agent 任务失败通常只是接口报错，本地智能体失败则可能改了不该改的文件，影响面完全不同。
这也可以解释为什么 Perplexity 这类以搜索和答案见长的公司会选择研究这个方向：它们已经有成熟的模型能力和检索工具，下一步自然是从“给出答案”走向“把答案转化为行动”。便携电脑只是一个起点，将来同样一套架构可能延伸到手机、车载系统，甚至智能家居设备上。
2. 智能体的核心概念与架构拆解
既然要聊智能体，先把概念边界划清楚。这个词被用滥了，但真正落到工程层面，它没那么玄乎。
一个最小可用的智能体，至少包含五个部分：
| 模块 | 作用 | 类比 |
|---|---|---|
| 模型（Model） | 负责理解用户请求、生成回复和调用决策 | 大脑 |
| 工具（Tool） | 暴露给模型的外部能力，如查天气、读文件、执行命令 | 手脚 |
| 记忆（Memory） | 保存会话上下文和跨轮次的关键信息 | 短期记忆 |
| 规划（Planning） | 把复杂任务拆解成多步执行计划 | 思考 |
| 执行环境（Environment） | 代码执行器、浏览器、本地文件系统等运行场所 | 工作台 |
模型是决策核心，它决定“下一步调用哪个工具”。工具是关键增量，如果没有工具，模型只是一个聊天机器人。记忆决定了智能体能否在多轮对话里不“失忆”。规划决定了它是只处理单步调用，还是可以完成“先查资料再写总结最后发邮件”的复合任务。执行环境则决定了它能触达的真实世界边界。
便携电脑智能体一个很大的不同，是把执行环境从“云端沙盒”换成了“你的电脑”。这意味着模型的工具列表里不再只有search_web、query_database，还可能有open_file、edit_code、run_shell、click_ui这些敏感能力。
智能体的运行循环通常被称为“Agentic Loop”，可以用这么一句话概括：
感知当前状态 → 结合用户目标 → 决定下一步动作 → 执行动作并观察结果 → 更新状态 → 循环直到任务完成。
这个循环看起来很简单，实际工程难度很大。每一步都可能出错：模型选错工具、工具返回格式异常、执行结果和预期不符、上下文过长导致遗忘。所以我们在做智能体系统时，不只是写一个模型调用，更重要的是写一个可靠的“执行循环框架”，把每一步的输入输出都纳入日志和校验体系。
在 Dify、Coze 这类平台上，你不需要手动实现这个循环。它们已经把“Agent 节点”封装好了，你提供工具描述，平台负责做模型调用、工具选择、结果返回。但对于做底层研发的团队来说，理解这个循环仍然很重要，因为性能瓶颈、错误恢复、上下文管理全都发生在这个循环内部。
3. Perplexity 便携电脑智能体研究的信号与判断
回到本次的主题。从公开信息来看，Perplexity 发布“便携电脑智能体”研究，最值得注意的并不是它计划发布某个具体硬件产品，而是它把 Agent 的研究重心放到了端侧执行层。
为什么这么说？
搜索和问答是 Perplexity 的基本盘。它的核心能力在于把网页信息检索与大模型生成结合，用户拿到的是带来源的答案。但检索天然是“只读”的。用户拿到答案之后，还要自己去打开 Excel、写代码、发邮件、整理文件夹。当你做这一步时，搜索工具的价值就断在了“信息获取”和“任务执行”之间。
智能体研究恰恰是来填补这个断层的。Perplexity 如果能把“搜索答案”的能力连接到“用户电脑上的操作”，那它的产品形态就不再是一个问答网站，而是一个真正的“个人工作助理”。用户在对话框里说一句“帮我找一下最近一周关于 XX 的新闻，整理成简报发到邮箱”，系统内部需要完成搜索、摘要、排版、调用邮箱客户端这四个动作，其中后两个动作很可能是发生在本地设备上的。
关于具体的设备形态、芯片方案、操作系统适配细节，目前还没有确定信息。更稳妥的判断是：这更像一个研究方向或产品预研，而不是马上要开卖的硬件。硬件并不是智能体的必需品，真正能不能跑起来，取决于软件层能不能把“设备权限、交互入口、执行反馈”这三件事做好。
对我们普通开发者而言，这项研究的价值主要在三方面：
第一，它代表一个趋势判断：智能体正在从“云端服务”走向“本地设备”。第二，它提醒我们关注端侧能力，比如本地模型部署、嵌入式向量库、系统权限管理。第三，它重新把“用户隐私”放到台面上，本地智能体接触到的数据比云端 Agent 敏感得多，开发者做产品时必须在权限设计上更克制。
不必急着追逐某一个具体的开源项目或硬件品牌，应该先掌握设备端智能体的通用设计方法。这部分能力通过主流智能体平台同样可以练习，而且成本更低。
4. 主流智能体开发平台与框架选型
如果你想验证上面的思路，可以直接用现成的智能体平台。目前最常见的选项有：
- Dify：开源 LLMOps 平台，支持知识库、工作流、Agent、API 发布，适合企业级落地。
- Coze（扣子）：字节跳动推出的智能体平台，中文友好，有大量现成的插件和 bot 应用场景。
- LangChain：Python 生态的 Agent 编排框架，灵活度高，适合深度定制。
- HiAgent：面向企业智能体开发的平台，功能偏工程化，支持流程编排和权限管理。
- Hermes：最近热度较高的开源智能体项目，核心思路是让模型自主调用工具完成任务，适合研究型开发者。
选型没有一个万能答案，关键看你的目标是什么：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 快速验证一个 Agent 应用 | Coze | 插件丰富，不需要写代码 |
| 企业内部落地和知识库问答 | Dify | 支持私有化部署，团队协作功能完整 |
| 深度定制自己的 Agent 框架 | LangChain | 可编程性强，社区资料多 |
| 研究端侧工具调用和执行循环 | Hermes 等开源 Agent | 可以阅读源码，深入改造 |
如果你过去没有接触过智能体开发，我的建议是从 Dify 开始。原因很简单：Dify 对环境的包容度最高，本地电脑上跑一个 Docker Compose 就能启动，界面操作直观，而且工作流和 Agent 节点都有可视化配置。先在平台上把流程跑通，再回头理解里面的原理，比一开始就面对 LangChain 那一堆抽象概念顺畅得多。
Diify 和 Coze 这类平台真正解决的，是把“模型调用、提示词编排、工具配置、会话管理、日志追踪”这些重复工程封装成可视化操作，让你把精力放在定义工具和梳理业务逻辑上。这也是为什么搜索热词里会有“ai智能体搭建”“智能体开发教程”“dify智能体平台”这些关键词——大家已经意识到，智能体开发正在从“纯代码研究”变成“平台化构建”。
5. 环境准备：完成智能体搭建的前置条件
下面进入实操。我以 Dify 为例，演示如何搭建一个最小可用的电脑信息查询智能体。
先说环境准备。本文的步骤不锁死版本，你使用的版本请以实际下载为准，但整体思路是通用的。
5.1 Docker 环境
Dify 推荐用 Docker Compose 启动。你需要先确认机器上安装了 Docker 和 Docker Compose。
docker --version docker compose version如果没有安装，请先到 Docker 官网下载对应操作系统的 Docker Desktop。安装完成后，确保 Docker 服务处于运行状态。
然后克隆 Dify 项目并启动。
git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动过程会拉取多个镜像，耗时取决于网络条件。启动成功后，浏览器访问http://localhost/install完成初始化设置。这里有一点要注意：Dify 的默认端口是 80，如果你的机器上已经有服务占用 80 端口，可以提前修改.env里的EXPOSE_NGINX_PORT，避免冲突。
5.2 模型配置
Dify 本身不自带模型，需要配置模型供应商的 API Key。目前它支持 OpenAI、Azure OpenAI、通义千问、智谱 GLM、Ollama 等主流来源。
如果你本地有显卡，推荐使用 Ollama 接入本地模型。原因很直接：便携电脑智能体的核心是“本地优先”，先用本地模型跑通流程，生产环境再换成更强的大模型，思路是一样的。
Ollama 的接入方式：
ollama pull qwen2.5:7b然后在 Dify 的“设置 → 模型供应商”里选择 Ollama，填写模型名称qwen2.5:7b，Base URL 填http://host.docker.internal:11434（Windows/Mac 访问宿主机 Ollama 时的常用地址），保存后即可在应用里选用。
5.3 创建一个空白应用
进入 Dify 控制台后，点击“创建空白应用”，应用类型选择“Agent”，选择你刚才配置的模型。这时你就有了一个最基本的 Agent 应用骨架，可以开始编排工作流和添加工具了。
6. 核心流程拆解：从问题到工具调用
理解了环境，我们来拆一个具体任务的完整流程。
假设我要做一个“电脑系统状态查询智能体”，用户可以对它提问：
- “我的磁盘还剩多少空间？”
- “帮我查一下 CPU 使用率。”
- “当前系统内存占用是多少？”
这个任务在云端很难做，因为云端服务访问不到你的本地系统资源。但在设备端智能体架构里，实现路径非常清晰。
整体流程可以拆成六步：
- 用户输入问题。
- Agent 节点判断用户意图。
- Agent 从工具列表里选择“系统信息查询”工具。
- 工具在本地执行系统命令。
- 把执行结果返回给 Agent 节点。
- Agent 生成自然语言回答。
看起来简单，但有一个关键设计：Agent 不能直接执行任意系统命令，必须通过一个受控的工具接口。工具内部做参数白名单校验，防止“帮我删掉系统文件”这类请求变成危险命令。
Dify 里如何实现这种工具管理？它支持两种方式：
第一种是内置工具，直接选择平台提供的能力。第二种是自定义工具，通过 OpenAPI Schema 接入你自己的 API。对于访问系统资源这种场景，通常更稳妥的做法是：写一个本地代理服务，暴露 HTTP 接口，Dify 通过自定义工具调用它。
这里的安全原则很关键：本地代理服务只监听本机地址，不暴露到公网；工具接口只接收白名单参数；所有执行命令都记录日志。智能体越往端侧走，权限边界越要设计得严格。
7. 完整示例：在 Dify 上编排智能体工作流
下面进入可以复制的具体操作。
7.1 准备一个本地系统信息查询接口
为了让 Dify 能够拿到本地系统信息，我们先用 Python 写一个轻量服务，对外提供/system/info接口。这个服务监听127.0.0.1，只允许本机访问。
# 文件路径：local_system_agent/server.py import json import platform import shutil import psutil from flask import Flask, jsonify app = Flask(__name__) def collect_system_info(): cpu_percent = psutil.cpu_percent(interval=1) memory = psutil.virtual_memory() disk = shutil.disk_usage("/") return { "hostname": platform.node(), "system": platform.system(), "cpu_percent": cpu_percent, "memory_total_gb": round(memory.total / 1024**3, 2), "memory_used_gb": round(memory.used / 1024**3, 2), "disk_total_gb": round(disk.total / 1024**3, 2), "disk_free_gb": round(disk.free / 1024**3, 2), } @app.route("/system/info", methods=["GET"]) def system_info(): return jsonify(collect_system_info()) if __name__ == "__main__": app.run(host="127.0.0.1", port=8765, debug=False)启动服务：
pip install flask psutil python server.py验证接口：
curl http://127.0.0.1:8765/system/info正常会返回一段 JSON，包含 CPU、内存、磁盘信息。注意：这个接口没有做鉴权，所以绝对不能监听在0.0.0.0，一旦暴露到局域网，任何人都可以查询你的系统状态。生产级别的接口必须加 Token 校验，这是底线。
7.2 在 Dify 中接入自定义工具
打开 Dify 控制台，进入应用的“工具”页面，点击“创建自定义工具”，通过 OpenAPI Schema 描述工具接口。Schema 可以简化写成下面这样：
openapi: 3.0.0 info: title: Local System Info Tool version: 1.0.0 servers: - url: http://127.0.0.1:8765 paths: /system/info: get: operationId: getSystemInfo summary: 获取本机CPU、内存、磁盘信息 responses: "200": description: 系统信息 content: application/json: schema: type: object properties: hostname: type: string cpu_percent: type: number disk_free_gb: type: number填写完成后，Dify 会自动把这个工具变成一个可被 Agent 调用的能力。
7.3 在 Agent 节点中配置提示词
进入应用编排页面，把默认的提示词改成带有工具说明的形式，避免模型在调用工具时犹豫不决。
你是一个运行在用户电脑上的本地智能体，主要负责查询系统运行状态。 你可以调用系统信息工具获取 CPU、内存、磁盘等数据。 回答时要用简洁、稳定的语气，并把工具返回的关键数值展示给用户。 如果用户请求涉及删除文件、修改配置、执行未知命令，必须明确拒绝并建议人工处理。这里设计了一个小的安全护栏：不是所有请求都直接执行，而是在提示词层面限定范围。更重要的是，工具层也要做二次拦截，不能只依赖提示词。
7.4 发布并调用工作流 API
Dify 应用配置完成后，点击“发布”，然后进入“访问 API”页面，复制 API 密钥和调用地址。用 curl 就能测试：
curl --location --request POST 'https://your-app-endpoint/v1/chat-messages' \ --header 'Authorization: Bearer YOUR_API_KEY' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "帮我查一下当前电脑的磁盘剩余空间", "response_mode": "blocking", "conversation_id": "", "user": "csdn-demo" }'响应里会包含来自 Agent 节点的最终回复文本。如果你打印出完整的 JSON，还能看到 Dify 返回中间步骤信息，包括模型用了哪个工具、工具返回了什么、最终生成了什么回答。
7.5 Python 调用示例
实际项目中，你更可能从自己的服务里调用 Dify。用 Python 封装一个客户端函数很简单：
```python import requests DIFY_API_URL = "https://your-app-endpoint/v1/chat-messages" DIFY_API_KEY = "app-xxxxx" def ask_agent(query: str, conversation_id: str = "") -> str: headers = { "Authorization": f"Bearer {DIFY_API_KEY}", "Content-Type": "application/json", } payload = { "inputs": {}, "query": query, "response_mode": "blocking", "conversation_id": conversation_id, "user": "csdn-demo", } resp = requests.post(DIFY_API_URL, headers=headers, json=payload, timeout=60) resp.raise_for_status() data = resp.json() return data.get("answer", "") if __name__ == "__main__": print(ask_agent("当前内存占用情况怎么样？"))调用前把 `DIFY_API_URL` 和 `DIFY_API_KEY` 替换成你实际发布应用的地址和密钥。这样你就把一个“能查磁盘剩余空间”的设备端智能体接到了自己的 Python 程序里。 #### 7.6 Java 调用示例 如果你平时用 Java 开发，也可以直接用 JDK 自带的 HttpClient 完成同样的调用，不需要额外引入第三方包。 ```java // 文件路径：src/main/java/com/example/agent/DifyClient.java import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; public class DifyClient { public static void main(String[] args) throws Exception { String apiUrl = "https://your-app-endpoint/v1/chat-messages"; String apiKey = "app-xxxxx"; String query = "帮我查一下当前 CPU 使用率"; String json = "{\"inputs\":{},\"query\":\"" + query + "\",\"response_mode\":\"blocking\",\"conversation_id\":\"\",\"user\":\"csdn-demo\"}"; HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(apiUrl)) .header("Authorization", "Bearer " + apiKey) .header("Content-Type", "application/json") .POST(HttpRequest.BodyPublishers.ofString(json, java.nio.charset.StandardCharsets.UTF_8)) .build(); HttpClient client = HttpClient.newHttpClient(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println("状态码: " + response.statusCode()); System.out.println("响应内容: " + response.body()); } }这段代码里最需要注意的地方是 JSON 字符串里的中文编码和转义，如果乱码，优先检查编译时是否启用了 UTF-8 编码。更稳妥的做法是用 JSON 库来构造请求体，而不是手动拼字符串。
8. 运行结果与效果验证
调用成功后，你会得到类似下面的响应（我隐藏了真实的 app 信息）：
你当前电脑的磁盘剩余空间约为 182.4 GB。 系统为 macOS，CPU 使用率 12%，内存已用 8.2 GB / 16.0 GB。这个结果说明整套链路已经跑通：用户问题 → Agent 判断 → 工具调用 → 结果返回 → 自然语言回复。
如果响应为空或者报错，第一步要看 Dify 应用里的“日志”页面。日志里会记录每个节点的输入输出，能明确看到是模型节点失败，还是工具节点失败，还是 HTTP 调用失败。排查时不要瞎猜，顺着节点日志走，问题很快就能定位。
这里也提醒一点：本地系统接口的返回是实时发生的，但 Python 的psutil.cpu_percent第一次调用通常返回 0.0，因为它需要采样间隔才能计算差值。这也是演示环境里常见但不影响流程的“假故障”，不算 bug。
9. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Docker Compose 启动失败 | 80 端口被占用 | 执行docker compose logs nginx | 修改.env中的EXPOSE_NGINX_PORT，然后重新启动 |
| Dify 无法连接 Ollama | Base URL 写错或 Ollama 未启动 | 在宿主机执行curl http://localhost:11434检查 Ollama 服务 | 将 URL 改为http://host.docker.internal:11434或http://172.17.0.1:11434（取决于 Docker 网络模式） |
| Agent 没有调用工具，直接答非所问 | 工具 Schema 配置错误或提示词不够明确 | 查看 Agent 节点日志，确认工具是否被正确加载 | 检查 OpenAPI Schema 里的operationId，并在提示词中明确说明“你可以调用系统信息工具” |
| 本地接口能访问，但 Dify 调不通 | 服务只监听了 localhost，Docker 容器访问不到 | 在容器里执行curl http://127.0.0.1:8765/system/info | 把 Flask 服务监听地址改为0.0.0.0，并设置 Token 鉴权（仅本地网络可控时可这么操作） |
| 响应速度很慢 | 本地模型推理耗时太长，或工具接口阻塞 | 查看日志里各节点耗时 | 更换更强的模型；把系统信息查询改成异步任务 |
| 中文乱码 | 请求编码不是 UTF-8 | 查看接口返回头和日志 | 在代码中显式指定 UTF-8 编码 |
10. 智能体工程化最佳实践
跑通 demo 只是第一步，真正做生产级智能体，下面几条建议值得提前想清楚。
10.1 权限控制永远前置
设备端智能体容易触碰敏感数据，权限设计是第一优先级。核心原则是“最小权限”：Agent 默认没有能力，每开放一个工具都要评估是否必要。工具内部要设置参数白名单，禁止把用户原始输入直接拼进系统命令。如果是本地 HTTP 服务，务必加 Token 校验，并且只监听回环地址。
10.2 给每个工具写清晰的描述
模型判断“该不该调用工具”靠的是工具描述。描述写得太模糊，模型会在多个工具之间犹豫；写得太复杂，又会挤占上下文窗口。推荐写成“工具名 + 功能 + 典型触发场景 + 输入参数”的结构，比如：getSystemInfo：获取本机系统信息。当用户询问 CPU、内存、磁盘、主机名时使用。不需要参数。
10.3 日志链路必须完整
云端 Agent 的链路长，设备端智能体的链路更复杂。每个节点都要记录：输入、输出、模型选择、耗时、错误信息。只有日志完整，才能回答“这个回答到底是模型生成的，还是工具执行返回的，还是两者拼装的结果”这个问题。
10.4 上下文管理要有策略
模型上下文窗口有限，多轮对话里 Agent 容易“忘事”。一个常见做法是只保留最近的若干轮对话，把早期对话摘要化。另一个做法是引入外部记忆，把不常变的事实存入向量数据库，每轮按需检索。
10.5 评估和回滚机制
智能体的行为带有概率性，不能像传统代码一样保证 100% 输出正确。上线前要准备一组典型用例，定期回归测试。每次调整提示词或工具描述时，都要跑一遍回归集，观察回答质量变化。如果线上版本表现异常，要能通过 Dify 的版本切换快速回滚到上一个稳定配置。
10.6 别把所有逻辑都塞进提示词
提示词能约束模型，但约束力是软性的。涉及安全拦截、参数校验、敏感操作确认这些硬规则，必须放到代码逻辑里。智能体架构要区分“软约束”和“硬约束”：提示词管表达风格和任务拆解，系统代码管权限和边界。
11. 总结与可执行的下一步
写完这一篇，你会发现设备端智能体和云端智能体之间的边界并没有那么遥远。Dify 这类平台让你在不需要写完整 Agent 框架的情况下，也能快速验证“本地工具调用 + 模型决策”的闭环。Perplexity 便携电脑智能体研究的核心信号，并不是某一个具体硬件，而是整个行业都在往“终端即 Agent 运行环境”这个方向走。
如果你刚接触这块，建议按下面的顺序实践一遍：
- 用 Docker 跑起一个 Dify 实例。
- 接入一个云端模型或本地 Ollama 模型。
- 照着这篇文章做一个“系统信息查询 Agent”，把本地工具接进来。
- 跑通 curl 和 Python 调用。
- 然后试着加一个“文件搜索工具”，让 Agent 能在指定目录里查找文件。
做完这五步，你基本就理解了智能体开发里最核心的一个模型：模型负责决策，工具负责执行，系统负责安全边界。这也是从“会调用 ChatGPT API”到“能做智能体产品”的关键跨越。
下一阶段值得深入的方向有三个：一是本地知识库和向量检索，让 Agent 理解你的个人文档；二是系统级 UI 操作能力，让 Agent 真正能模拟点击和输入；三是多智能体协作，让不同功能的 Agent 分工完成复杂任务。选择一个方向扎进去，比停留在“AI 很厉害”的阶段有价值得多。
