OpenClaw本地部署全攻略：从飞书接入到Ollama大模型配置

1. 为什么要做 OpenClaw 本地部署：需求分析比安装更优先

1.1 OpenClaw到底是什么：一个能跑在你自己电脑上的 Agent 运行时

先说结论：OpenClaw 并不是一个简单的聊天机器人，而是一套开源 AI Agent 运行时环境。把它部署到本地后，你可以把飞书、Discord、Telegram、Teams 这类 IM 工具变成 Agent 的交互入口。用户在飞书里发一条消息，就能让 Agent 帮你查资料、调用工具、按预设流程处理任务，甚至串联多个 API 完成一整套操作。

这个项目最有吸引力的地方在于"所有权"三个字。当你使用云端 Agent 服务时，对话记录、上下文记忆、文件附件都存在别人的服务器上，你无法真正掌控。而 OpenClaw 本地部署之后，所有会话记录、模型调用凭证、Agent 记忆、任务日志都落在你自己机器的目录下。对公司团队来说，这意味着敏感数据不出内网；对个人玩家来说，这意味着你可以随便折腾，不怕弄坏共享服务，也不用按调用量付费。

我一直强调一句话：部署开源项目之前，先花 30 分钟想清楚你要解决什么问题。OpenClaw 适合以下几类场景：一是你的团队平时重度使用飞书，想做一个能响应群聊命令的 AI 助手；二是有数据隐私要求，AI 交互的记录不能出公司网络；三是你想把多个本地大模型（DeepSeek、Qwen、MiniMax 等）串联到一个统一的 Agent 框架里，通过 IM 去调用。如果你的需求只是偶尔翻译、润色文本，那直接用在线大模型就够，没必要折腾本地部署。既然标题是"全系统指南"，我下面会把从环境准备到飞书接通、再到排错的全链路讲透。

1.2 本地部署与云端 Agent 的取舍：别只看成本

很多人纠结"OpenClaw 和 WorkBuddy 哪个好"，其实这种对比容易陷入误区。WorkBuddy 这类产品通常是一体化的桌面端 Agent 工具，安装即用，交互体验顺滑；OpenClaw 则是一套可以自由组合的运行框架，你需要自己配模型、配渠道、配 Prompt。两者定位完全不同：前者是成品，后者是半成品但自由度极高。

从我的实际体验来看，选择本地部署最大的收益不是省钱，而是可控性。云端 Agent 服务可能随时调整接口策略、限制调用频率，或者因为数据合规问题在某些地区不可用。本地部署后，你的 Agent 完全由你定义：用哪个模型、给多长上下文、接哪些渠道、允许多大并发，全部自己说了算。

当然，本地部署也有代价。第一，硬件成本转移到了你自己身上；第二，维护责任从平台转移到了你身上；第三，性能上限受限于你的电脑或服务器配置。如果你只是偶尔用用，云端服务可能更省事；如果你要做一个长期运行、可定制、数据敏感的 Agent 服务，OpenClaw 本地部署是更值得投入的方向。

1.3 为什么把飞书作为接入端：团队协作场景的真实需求

飞书在团队协作场景里的渗透率很高，而且它的开放平台提供了完整的机器人 API。你创建的飞书机器人既能被添加到群聊中响应 @ 命令，也能支持单聊私信，还能通过事件订阅机制实时接收消息。

选择飞书接入 OpenClaw，意味着 Agent 不只是你电脑上的一个终端程序，而是变成了团队里一个"能干活"的成员。团队成员不需要学习任何命令行操作，只需要在飞书群里 @ 一下机器人，就可以触发 Agent 干活。这种交互门槛几乎为零，非常适合非技术背景的同事参与。

2. 硬件选型与运行环境准备：这步偷懒后面全是坑

2.1 硬件配置建议：按模型规模分档

本地部署 OpenClaw 本身消耗的资源很小，真正的资源大头在本地大模型。我做了一个分档参考：

我的个人经验是：如果只是把 OpenClaw 当作飞书群里的知识问答机器人，16GB 内存 + 7B 量化模型足够入门。但如果你希望 Agent 具备工具调用、多步骤任务规划能力，模型推理质量就变得很关键，建议上 14B 以上的模型，内存尽量 32GB 起步。条件允许时，加一块显卡会带来质的飞跃，因为 CPU 推理真的会让 Agent 的链式推理过程显得非常拖沓。

2.2 安装 Node.js：版本选择比想象中重要

OpenClaw 基于 TypeScript 生态开发，运行时依赖 Node.js。这里我要特别强调一个细节：不同版本的 Node.js 对 OpenClaw 的兼容性差异很大。根据我踩过的坑，建议使用 Node.js 20 LTS 或更新的 22 LTS 版本，尽量避免使用 Node.js 18 及以下版本。旧版 Node.js 对 WebSocket、Fetch API 的原生支持不完整，容易在飞书长连接模式上报一些莫名其妙的错误。

Windows 上可以通过 winget 快速安装：

winget install OpenJS.NodeJS.LTS

Linux 上建议通过 NodeSource 仓库安装：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs

安装完成后务必打开新终端，验证版本：

node -v npm -v

如果node -v能正常输出版本号，那么运行环境基础就绪了。这一步看起来基础，但我见过很多人在此栽跟头：系统里同时存在多个 Node 版本，导致 npm 全局安装的包落到另一个版本目录里，怎么启动都找不到命令。

2.3 顺便装好 Git 和常用调试工具

OpenClaw 的配置管理和后续升级都会用到 Git。虽然 npm 安装方式不需要你手动克隆仓库，但当我需要查看最新源码、对比版本差异或提交 issue 时，Git 是绕不开的。Linux 下执行：

sudo apt-get install -y git curl wget

Windows 用户安装 Git for Windows 即可。此外我建议准备好一个能看日志的终端工具。Windows 上推荐 Windows Terminal，Linux 上直接使用系统终端就行。后面排查问题时，你要反复查看 OpenClaw 的启动日志，一个好用且支持搜索的终端能省下大量时间。

3. OpenClaw 主程序安装与初始化：从空目录到跑起来

3.1 用 npm 全局安装 OpenClaw

环境准备好之后，安装 OpenClaw 本体其实很简单。官方支持通过 npm 全局安装：

npm install -g openclaw

装完后验证一下：

openclaw --version

如果命令不存在，请回头检查 Node.js 的全局 bin 目录是否在 PATH 环境变量里。Linux 上 npm 全局路径通常是/usr/local/bin或~/.npm-global/bin，Windows 上则是%APPDATA%\npm。这个细节不处理好的话，后面每次启动都会碰壁。

3.2 openclaw init：初始化过程到底做了什么

执行安装后的第一步，我建议先运行初始化命令：

openclaw init

这个过程会做以下几件事：在你当前用户目录下创建.openclaw配置文件夹；生成一份默认的配置文件（通常是setup.json或类似结构的配置文件）；预置 Agent 的基础信息和默认模型参数；扫描当前可用的频道类型。

初始化完成后，你可以在.openclaw目录下看到一个配置文件。打开它，你会看到类似这样的结构：

{ "name": "my-openclaw-agent", "ai": { "provider": "openai", "baseUrl": "http://localhost:11434/v1", "apiKey": "ollama", "model": "qwen2.5:14b" }, "channels": { "lark": { "appId": "", "appSecret": "", "verificationToken": "", "encryptKey": "" } } }

不同的版本字段名可能略有差异，但核心配置项是一样的：Agent 名称、模型接入参数、频道参数。我建议你花几分钟逐项看懂这个文件的含义，而不是盲目填空。后面所有问题排查都集中在这里。

3.3 首次启动测试：先不接飞书，验证系统本身

我强烈建议在接入飞书之前，先做一次不带频道的启动测试。因为飞书配置一旦出错，日志里混着 OpenClaw 自身信息和飞书 API 报错，排查难度成倍增加。你可以在初始化后直接启动：

openclaw start

如果配置文件中暂时没有可用的频道，启动过程可能会提示"未配置任何 channel"或者进入默认终端模式。请先确认主程序能够正常加载、模型能够正常调用，再继续后面的飞书接入。这一步就像一个新员工入职先培训再上岗，别一上来就推进群聊。

4. 本地大模型与 OpenClaw 对接：Ollama 方案最省心

4.1 为什么首选 Ollama：OpenAI 兼容接口是关键

本地部署大模型有多个方案：Ollama、vLLM、Llama.cpp、LocalAI、LM Studio 等。对 OpenClaw 来说，Ollama 是最友好的选择，原因很简单：它默认提供 OpenAI 兼容的 API 接口。OpenClaw 只需把provider配置成openai，把baseUrl指向 Ollama 的地址，其他代码逻辑完全不用改。

Ollama 的安装同样非常友好。Linux 上一条命令搞定：

curl -fsSL https://ollama.com/install.sh | sh

Windows 用户直接去官网下载安装包，安装后 Ollama 会常驻系统托盘。装完后先确认服务在线：

ollama list

如果这个命令能正常输出模型列表（即使为空），说明 Ollama 服务已经在本地运行了。

4.2 模型选择与拉取：DeepSeek、Qwen、MiniMax 怎么选

本地部署的模型选择直接决定了 Agent 的智商上限。从当前开源模型的热度和 OpenClaw 社区的使用反馈来看，三款模型值得关注。

DeepSeek 系列：DeepSeek-R1 的推理能力很强，适合需要深度思考、多步骤推理的任务。量化版本在普通配置上也能跑，比如deepseek-r1:7b在 16GB 内存的机器上可以流畅运行。

Qwen 千问系列：qwen2.5:14b是我个人最常用的模型。它在中文理解、工具调用指令遵循方面表现均衡，响应速度比同量级的其他模型更快。如果你的机器内存足够，这个模型值得首选。

MiniMax H3：这是近期社区热度上升很快的模型。MiniMax 系列在长文本生成和中文创意内容上表现出色，但对显存或内存的要求稍高。搜索热词里也出现了minimax h3 本地部署相关的需求，说明不少人在尝试用它做 Agent 底层。这里要提醒一句：不要只看模型榜单，要结合你的硬件条件和实际使用场景选模型。

拉取模型：

# 拉取 7B 级别入门模型 ollama pull deepseek-r1:7b # 拉取 14B 级别均衡模型 ollama pull qwen2.5:14b # 拉取 MiniMax H3（注意确认当前 Ollama 支持情况） ollama pull minimax

拉取完成后，用ollama list确认。然后在终端直接对话测试：

ollama run qwen2.5:14b "用一句话介绍你自己"

这一步很重要。如果模型本身输出质量差、响应慢或直接报错，后面接入 OpenClaw 只会放大问题。先确保模型在原生环境里表现正常，再谈集成。

4.3 把模型配置写进 OpenClaw：注意 baseUrl 的地址

Ollama 的默认服务地址是http://localhost:11434。但是这里有个细节：OpenClaw 走的是 OpenAI 兼容接口，因此baseUrl要写成：

http://localhost:11434/v1

apiKey可以填任意非空字符串，Ollama 默认不校验密钥，但不能留空。

对应配置如下：

{ "ai": { "provider": "openai", "baseUrl": "http://localhost:11434/v1", "apiKey": "ollama", "model": "qwen2.5:14b" } }

如果你把 OpenClaw 部署在一台服务器上，而 Ollama 跑在另一台机器上，那么baseUrl要改成对应的局域网 IP。比如http://192.168.1.100:11434/v1。同时要注意，Ollama 默认只监听本机回环地址，你需要设置环境变量OLLAMA_HOST=0.0.0.0让它监听所有网卡。

4.4 进阶玩法：接 Dify、RAGFlow 做知识库增强

搜索热词里频繁出现dify本地部署教程、ragflow本地部署。如果你想打造企业级的本地 AI 知识问答系统，光靠大模型自身记忆是不够的，需要用 RAG（检索增强生成）技术外挂知识库。

RAGFlow 是一个开源的 RAG 引擎，它能把你上传的文档做切分、向量化，并存到向量数据库里。OpenClaw 的 Agent 在进行任务规划时，可以调用 RAGFlow 提供的 API 获取相关知识片段，然后大模型基于这些片段生成回答。这样做的好处是回答内容可以被溯源，减少大模型一本正经地胡说八道。

这种组合的实现方式通常是：RAGFlow 以独立服务运行，OpenClaw 通过配置额外的工具接口或 HTTP 请求来调用它。具体集成方式取决于你使用的 OpenClaw 版本，但核心思路是让 Agent 的工具列表里多一个"知识库检索"能力。如果你追求的是"飞书群里能问公司制度、项目文档"这类需求，这一步几乎必不可少。

Dify 也是一个类似的低代码 AI 应用平台，它自带模型管理、知识库、工作流编排功能。有些用户选择把 Dify 部署在 OpenClaw 前面，用 Dify 统一管理模型和知识库，OpenClaw 只作为消息转发层。不过这种方式会增加一个中间层，故障排查链路也更长。初学者建议先用 Ollama + OpenClaw + 飞书这条最小链路跑通，再加知识库增强。

5. 飞书接入全流程：从开放平台到 OpenClaw 跑通消息

5.1 在飞书开放平台创建企业自建应用

飞书接入的第一步，是去飞书开放平台创建一个应用。这一步的操作路径通常是这样：登录飞书开放平台，进入开发者后台，选择"创建企业自建应用"，填写应用名称和描述，然后提交创建。

创建成功后，你会在应用凭证页面看到三个关键信息：App ID、App Secret、以及后面可能需要的Verification Token。这三个参数后续要填到 OpenClaw 的配置里，建议暂时保存在一个文本文件里。

这里要特别说明一下：飞书的开放平台界面会经常调整，但"创建企业自建应用"这个入口一般都不难找。如果你所在的企业已经禁用了开发者权限，需要找管理员开通，或者用个人飞书账号创建一个测试企业来试验。

5.2 添加机器人能力并配置权限

应用创建完成后，需要在"应用能力"里添加机器人能力。添加后，你的应用就有了一个机器人身份，可以出现在群聊和单聊中。

接着要配置权限。飞书的权限模型很细，机器人要收发消息，通常需要以下几类权限：

在飞书开放平台的"权限管理"页面里搜索并开通这些权限。权限开通后需要等待生效，通常在几分钟内。有一个经验是：如果你在调试中发现机器人收不到消息，多半是权限没配全，而不是代码有问题。

5.3 事件订阅：长连接模式比回调模式省心

飞书机器人要能收到用户的消息，必须配置事件订阅。飞书支持两种方式：

一种是回调 URL 模式：飞书把用户消息事件通过 HTTP POST 推送到你配置的公网 URL。这要求你有公网 IP 或域名，还要配置 SSL 证书，对于本地部署来说非常麻烦。

另一种是长连接模式（WebSocket）：飞书开放平台提供了长连接服务，你的应用主动建立 WebSocket 连接来接收事件。这种方式不需要公网地址，非常适合跑在家里电脑或公司内网服务器上的 OpenClaw。

配置事件订阅时，需要添加事件回调。重点添加的事件类型是im.message.receive_v1，即收到消息时触发。在飞书后台的"事件与回调"页面，添加这个事件，然后选择长连接模式。如果界面提示你配置加密策略，记得保存好 Encrypt Key。

5.4 将飞书参数填入 OpenClaw：一步步核对

现在到了关键环节：把飞书应用的信息填到 OpenClaw 配置里。回到前面说的配置文件，找到channels下的lark或feishu部分（不同版本可能命名有差异，但基本都能对应上）：

{ "channels": { "lark": { "appId": "cli_xxxxxxxxxxxxxxxx", "appSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "verificationToken": "xxxxxxxxxxxxxxxx", "encryptKey": "xxxxxxxxxxxxxxxx" } } }

填写时请注意：

• appId是飞书应用的唯一标识，以cli_开头。
• appSecret和verificationToken在应用凭证页面可以找到。
• encryptKey是在配置事件订阅加密策略时才有的。如果没有启用加密，可以留空或填任意值，但一定要和飞书后台的配置保持一致。
• 飞书后台需要开启"机器人"能力，否则应用不会以机器人身份出现在聊天中。

填好后保存配置文件，重启 OpenClaw：

openclaw stop openclaw start

5.5 群聊和单聊实测：消息链路验证

启动成功后，去飞书里找到你的应用机器人，先发起单聊，发一句"你好"。正常情况下，OpenClaw 的日志里会出现一条收到消息的记录，然后模型会生成回复并通过飞书 API 回传。

群聊场景下，你需要先把机器人拉进群，然后在群里 @ 机器人再发消息。这里有个容易忽略的细节：飞书机器人默认只有在被 @ 时才会响应群聊消息，这是权限模型决定的。如果你希望机器人回复群里每条消息，需要额外配置，但我个人不建议这么做——群里消息太多，容易触发 OpenClaw 的并发限制。

如果单聊正常但群聊无响应，第一步去开放平台检查"事件订阅"里是否包含了群聊消息事件，第二步确认群里是否成功添加了机器人，第三步查看 OpenClaw 日志里有没有收到消息事件。按这个顺序排查，大多数问题都能快速定位。

6. 实际运行中的 Agent 配置与体验调优

6.1 Agent 频道选择的逻辑：多平台同时接还是单接

热搜词里有openclaw agent怎么选择channel，这说明不少人在接入飞书后还想着接 Discord、Teams 等平台。OpenClaw 本身支持配置多个 channel，但我不建议一上来就全接。原因如下：

每个 Channel 会创建独立的会话管理上下文。当你同时接入飞书、Teams、Telegram 时，Agent 需要分别维护每个平台每个用户的会话状态，内存占用和心理负担都成倍增加。而且首次接入某个平台时，认证流程、权限配置、消息格式差异都需要逐一调通。

我的建议是：先用飞书单平台跑两周，确认 Agent 在真实群聊环境中的表现稳定了，再考虑接入第二个平台。多平台接入的最大价值在于统一 Agent 行为，但前提是你先把单一平台的行为模式调教好。

6.2 会话管理、并发限制与记忆清理

OpenClaw 的每个会话对应一个持续对话上下文。当你通过飞书与 Agent 长时间对话，上下文会不断累积。本地模型受限于上下文窗口长度，当对话历史超过窗口大小时，Agent 要么报错，要么开始忘事。

这里我分享一个实践经验：给 Agent 设定一个会话重置策略。可以在配置里设置最大历史消息数或上下文长度阈值，超过后自动裁剪早期消息。举个例子，如果模型上下文窗口是 8K，你可以配置 Agent 只保留最近 20 轮对话，超出部分从记忆中滑出。这样既保留了关键上下文，又避免触发长度超限。

另外，OpenClaw 在运行过程中会在.openclaw目录下生成会话文件。这些文件记录了每次对话的完整上下文。你的内存紧张时，注意清理无用的历史会话。但要留意，删除会话文件意味着 Agent 会忘记那部分历史，操作前考虑一下是否有保留必要。

6.3 飞书输出截断：长回复的三种解决思路

搜索热词里有一条非常具体的问题：openclaw在飞书输出容易被截断。这条我要展开讲讲。

飞书对单条消息的长度有硬性限制，超出部分会被截断。而大模型经常生成长文，于是你在飞书里看到的就是一句话说到一半戛然而止。解决思路有三种：

思路一是调整 OpenClaw 的消息分块设置。在配置中设置合理的最大消息长度，让 OpenClaw 自动把长回复拆分成多条消息发送。比如设置chunkSize: 2000，超过这个长度的回复，OpenClaw 会分批发送。

思路二是让 Agent 学会用摘要式回复。在 Agent 的系统提示词里明确要求：默认回复保持在 200 字以内，信息量大的内容优先用列表和结构化文本表达。这样能从源头减少长文本产生。

思路三是引导 Agent 使用文件消息。当回复内容确实很长时，让 Agent 把内容写入一个本地文件，然后通过飞书发送文件消息。飞书对文件大小的限制比消息长度宽松得多，你可以在文件里塞下完整的长文。

三种思路各有适用场景，我目前采用的是思路一加思路二的组合：既设置了消息分块，也在提示词里限定了回复篇幅。实际效果是普通问答完全没问题，大段文案偶尔分两条发也不会影响阅读。

7. 高频报错排查与稳定性维护心得

7.1 session file locked (timeout 60000ms) 错误定位与根治

这个报错在 OpenClaw 用户群里出现频率极高：agent failed before reply: session file locked (timeout 60000ms)。第一次遇到时我也蒙了，花了不少时间才搞明白机制。

OpenClaw 在管理 Agent 会话时，会为每个会话生成一个会话文件。为了防止多个进程同时写入同一个会话文件造成数据损坏，它引入了文件锁机制。当进程 A 读取或写入会话文件时，会创建锁；如果进程 B 在这期间也试图访问同一个会话文件，B 会等待锁释放。默认等待超时是 60000ms，也就是 60 秒。如果 60 秒内锁没释放，OpenClaw 就直接报错并放弃响应。

什么情况下会导致锁被长期持有？最常见的是启动了多个 OpenClaw 实例，且两个实例使用相同的会话文件或相同的 Agent 配置。比如你在终端openclaw start启动了一个实例，然后又在另一个终端重复启动，两个进程同时抢同一个会话文件，就会触发锁超时。

排查步骤是这样的：

第一步，用系统命令查看是否有多个 OpenClaw 进程在运行：

ps aux | grep openclaw

Windows 上可以用任务管理器或 PowerShell：

Get-Process | Where-Object { $_.ProcessName -like '*openclaw*' }

如果发现多个进程，保留一个，其余全部杀掉。

第二步，进入.openclaw目录，找到对应会话目录，删除残留的锁文件。锁文件的命名通常是session.json.lock或类似格式。直接删除没关系，会话主体文件还在，只是跳过了锁的等待。

第三步，预防复发。如果你确实需要并发处理多个任务，应该使用不同的 session ID 或不同的 Agent 配置，而不是同时开两个完全相同的实例。可以在启动命令中指定不同的会话标识，或者在配置文件中为不同频道分配独立的会话目录。

这个错误的根源不在于代码有 bug，而在于使用方式超出了 OpenClaw 的设计预期。想清楚"每个会话文件同时只能被一个进程持有"，你就能理解怎么避免它了。

7.2 大模型连接失败：从 Ollama 到 OpenClaw 逐层排查

另一个高频问题是 OpenClaw 启动没问题，但飞书里一提问就回复"连接失败"或"上游无响应"。这类问题的排查应该从下往上逐层做。

首先测试 Ollama 本身是否正常：

curl http://localhost:11434/api/tags

如果返回值不是 JSON 格式的模型列表，说明 Ollama 没启动或端口不对。确认 Ollama 进程在运行，确认监听端口。

然后测试 OpenAI 兼容接口：

curl http://localhost:11434/v1/models

这个地址是 OpenClaw 真正访问的地址。如果返回404或无法访问，说明 Ollama 版本不支持兼容接口或路径不对。

最后检查 OpenClaw 配置文件里的baseUrl、model是否正确。我见过不少人把模型名写错，比如 Ollama 里拉取的是qwen2.5:14b，配置里却写成了qwen2.5-14b，中划线不合规导致模型找不到。模型名必须以ollama list输出的实际标识为准。

7.3 长期稳定运行的三条经验

部署不是终点，稳定运行才是。我根据自己的使用经验，整理了三条维护建议供你参考：

第一条，把 OpenClaw 注册为系统服务。Linux 上使用 systemd 管理 OpenClaw 进程，可以做到开机自启、崩溃自动重启、日志统一管理。Windows 上可以使用 NSSM 或计划任务实现类似效果。不要依赖手动启动，否则服务器一重启你就得手动恢复。

第二条，定期查看日志。OpenClaw 的日志会记录消息收发、模型调用、异常堆栈。我习惯每周看一次日志，重点关注持续的报错记录和异常的响应耗时。日志里出现timeout、locked、rate limit这些关键词时，后续较大面积的问题往往已经埋下伏笔了。

第三条，做好配置备份。.openclaw目录里的配置文件和会话数据是 OpenClaw 的全部家当。升级版本、迁移服务器之前，先把整个目录打包备份。别看这个动作简单，真遇到版本升级后配置不兼容的情况，备份能让你五分钟内回滚到可用状态。

7.4 最后再分享一个实用技巧

如果你经常在飞书群里用 OpenClaw 处理文档类任务，建议在 Agent 的提示词里提前注入"飞书消息格式"的约束。比如告诉它：列表用1.2.编号，代码块用反引号包裹，回复尽量分段不要一长串。这些约束看似琐碎，却能大幅提升飞书场景下的可读性。AI Agent 的可控性往往不是靠模型能力，而是靠这些被反复打磨的细节规则。

我从开始折腾 OpenClaw 到现在，最深的体会是：一个本地部署的 AI Agent，真正有价值的不是那层"AI"光环，而是你能完全掌控它、改造它、让它贴合自己的使用习惯。飞书接入只是把这份掌控力带到了团队协作的第一线。当你看到同事在群里 @ 你们的 Agent 机器人解决了一个实际问题，那种"这系统是我搭的"的感觉，才是折腾这一切的意义所在。