LinkClaw 本机工作台：把 OpenClaw、Hermes 和文件管道放到一起

前面几篇我讲了 LinkGo 的保格式翻译、术语记忆和本机沙箱。今天想展开讲一个更底层的设计：为什么我会把 OpenClaw、Hermes 这两类原版智能体接进 LinkGo，并且让它们和 LinkGo 自己的文件翻译管道、本机沙箱、模型配置、术语记忆一起工作。

这不是为了“多接两个智能体显得更强”。我的真实动机很简单：真实文件任务往往不是一个模型回答能解决的，它需要一个能规划、能读写文件、能调用工具、能回到产品交付链路里的执行系统。

很多 AI 产品处理文件时，会停在两个极端。

一种是纯聊天：你上传文件，模型告诉你“建议这样做”。它能解释、能总结、能翻译片段，但真到 Word、PPT、Excel、PDF、字幕、批量目录和本机脚本，就很难把事情完整做完。

另一种是完全自动化：什么都让智能体自己摸索。听起来很爽，但真实落地时很容易遇到问题：它读了哪些文件？写到了哪里？中间失败怎么恢复？模型配置从哪里来？术语和翻译记忆有没有用上？最终结果是不是可下载的正式文件？

LinkGo 想做的是中间那条路：让智能体能执行，但把执行放进本机沙箱和文件交付链路里。

为什么需要 OpenClaw 和 Hermes？

LinkGo 自己已经有文件翻译、术语库、翻译记忆、OCR、字幕、Office 写回、排版检查这些能力。那为什么还要接 OpenClaw 和 Hermes？

因为它们擅长的是“开放任务执行”。

比如用户不是只说“翻译这个 Word”，而是说：

帮我看这个目录里哪些文件还没翻译，先把 Word 和 PPT 翻成日语，再把结果整理成一个清单，最后检查有没有漏译。

这类任务不是单一文件翻译。它包含目录扫描、文件筛选、任务拆分、调用翻译管道、结果核对、生成清单、继续追问。更像一个小型项目。

OpenClaw 和 Hermes 适合承担“智能体执行层”的角色：理解多步骤目标、调用工具、读取工作区、跟踪过程、在失败后尝试修复。

而 LinkGo 更适合承担“产品交付层”的角色：管理用户、附件、模型、术语、记忆、权限、运行记录、下载结果、前端体验。

所以我不想把它们改造成 LinkGo 的一个普通函数，也不想让它们绕过 LinkGo 自己的能力。

更合理的结构是：

• OpenClaw / Hermes 保留原版智能体能力
• LinkClaw 负责本机启动、停止、状态、日志、模型桥接和任务桥接
• LinkGo 文件管道负责结构化解析、翻译写回、质量检查和最终交付
• 主项目聊天页负责用户入口、附件、权限、结果展示和继续追问

这样两个世界才不会互相打架。

LinkClaw 这一层到底做什么？

我把桥接层叫 LinkClaw。它不是一个新的大模型，也不是替代 OpenClaw / Hermes 的壳。

它主要做几件很实际的事：

1. 在本机启动和管理 OpenClaw / Hermes
2. 把 LinkGo 里的模型配置同步给两大智能体
3. 把用户上传的附件和工作区同步到智能体能看到的位置
4. 把任务、上下文、权限模式和沙箱范围整理后交给对应引擎
5. 把 stdout、stderr、trace、session 等运行过程折叠回 LinkGo 的 Agent Run 面板
6. 把最终回答和结果文件交还给 LinkGo，而不是让用户去日志目录里找

这件事看起来像“胶水代码”，但真正落地时，胶水往往决定体验。

比如 OpenClaw 和 Hermes 各自有自己的 Web、Gateway、CLI、运行状态、依赖、日志和配置方式。LinkGo 不能假装它们不存在，也不能把这些细节全部暴露给普通用户。

所以 LinkClaw 做的是一层本机适配：保留原版能力，但把它们放进 LinkGo 的产品边界里。

文件翻译为什么不能让智能体自己拆？

如果只是处理纯文本，智能体自己读文件、自己改文件，好像也能跑。

但真实 Office 文件不一样。

一个 DOCX 里有段落、表格、样式、脚注、批注、页眉页脚；PPTX 里有文本框、形状、母版、备注页；Excel 里有单元格、富文本、公式、样式；字幕有时间轴和分行；PDF 还涉及版式和重建。

如果让智能体临时写脚本去拆这些文件，很容易出现三个问题：

• 结构丢失：翻译完只剩纯文本
• 写回不稳：格式、样式、文本框、表格被破坏
• 结果不可控：不同模型、不同任务，每次临时脚本都不一样

所以 LinkGo 的思路是：智能体不应该重新发明文件管道。

LinkGo 文件管道会把文件解析成结构化 JSON，让每个可翻译单元有稳定编号。智能体只需要处理 translated 字段，保留结构字段、编号、格式信息和保护片段。

常见流程大概是：

1. inspect：识别文件类型、语言和可处理能力
2. index：拆出可翻译单元，形成结构化索引
3. template：生成翻译模板
4. 智能体分片翻译，保持术语和上下文一致
5. validate：检查漏译、空译、语言残留、数字和保护片段
6. apply-retry：只重试失败片段，不重跑整个文件
7. write：调用 LinkGo 原有写回能力重建最终文件

这个设计有一个关键点：文件结构的真相在 LinkGo 管道里，不在模型临时生成的脚本里。

OpenClaw / Hermes 负责规划、调用和补救；LinkGo 负责文件专业能力和交付质量。

这也是我认为两者结合最有价值的地方。

沙箱可以做什么？

用户常常问：既然叫本机沙箱，那它是不是可以做任何事情？

我的回答会更谨慎一点：它可以做很多本机任务，但前提是用户授权、权限模式允许，并且所有动作都应该在清楚的边界里发生。

在这个前提下，本机沙箱能做的事情就很多了。

它可以做文件类任务：

• 批量读取目录
• 整理文件清单
• 批量翻译 Word、PPT、Excel、字幕
• 提取表格并导出 XLSX
• 对比原文和译文
• 生成审校报告
• 把结果归档到指定输出目录

它可以做开发和脚本类任务：

• 运行 Python / PowerShell / shell 命令
• 检查依赖是否缺失
• 生成小工具脚本
• 读取日志并定位错误
• 启动或停止本机服务
• 对项目文件做受控修改

它也可以做知识和联网类任务：

• 根据任务需要检索术语
• 查找公开标准或官方文档
• 把搜索结果作为只读证据注入翻译或审校
• 结合术语库、翻译记忆和长期偏好做输出

但这里最重要的不是“能做很多”，而是“能不能知道它做了什么”。

所以 LinkGo 里本机沙箱强调几个边界：

• 本机优先：只允许 127.0.0.1 / localhost 控制本机能力
• 工作区边界：只读、标准、完整权限对应不同能力
• 日志可追踪：stdout、stderr、trace、session 都能回看
• 结果可交付：用户看到的是最终文件和摘要，不是满屏内部调试
• 密钥脱敏：模型 Key、token、password 不应该暴露到日志和页面

智能体越能干，越要把边界说清楚。

本地部署为什么重要？

如果只是普通聊天，云端当然方便。

但文件翻译和本机自动化经常涉及企业资料、合同、财报、技术手册、客户文档、字幕素材、项目源码、本机目录结构。这些东西不是每个团队都愿意直接丢到外部服务里。

本地部署的意义不是完全拒绝云模型，而是把选择权拿回来。

LinkGo 的方向是：

• 文件目录默认留在本机
• 本机沙箱只在运行程序的电脑上可用
• 在线模型和本地模型都可以接
• OpenClaw / Hermes 子进程只拿到本轮需要的上下文
• 模型配置、术语库、记忆库、附件和工作区由主项目统一管理

这样用户可以按任务选择模型。

隐私敏感任务可以走本地模型或内网模型；复杂推理任务可以走在线模型；文件处理和结果写回仍然在本机完成。

这种组合比“全云端”更麻烦，但对很多真实办公场景更踏实。

OpenClaw 和 Hermes 分别适合什么？

我不会把它们简单分成“谁更强”。

更准确地说，它们是两类不同风格的执行引擎。LinkGo 要做的是让用户可以在同一个沙箱入口里选择合适引擎，而不是为了选择引擎而换一整套工作流。

OpenClaw 适合偏工具化、Gateway、任务执行和本机控制台的场景。它的运行过程、技能列表和工具轨迹适合被折叠成 Agent Run，让用户知道它在做什么。

Hermes 适合偏多轮、会话、上下文注入和技能协同的场景。它的历史压缩、hook、技能同步和运行会话也能给复杂任务提供更好的连续性。

但无论选哪一个，LinkGo 都希望保持几件事不变：

• 用户还是在 LinkGo 聊天页上传文件和下指令
• 模型配置还是跟随主项目设置
• 术语、记忆、知识库开关还是从 LinkGo 传入
• 文件翻译仍优先使用 LinkGo 文件管道
• 最终结果仍回到 LinkGo 下载和继续追问

对用户来说，选择 OpenClaw 或 Hermes 不应该意味着换一个产品。

它应该只是选择本轮任务的执行引擎。

这个组合最终想解决什么？

我做这个组合，想解决的不是“让 AI 看起来更像人”。

我更关心的是：让 AI 在真实工作里少停在建议层，多往交付层走一步。

比如这些需求：

• 把一整个目录里的 Word 和 PPT 翻成日语，保留格式
• 翻译后检查有没有中文残留、数字丢失、术语不一致
• 把双语文件抽成对齐语料，导出 Excel
• 先读材料，总结重点，再生成一份演示稿
• 检查某个本机项目为什么启动失败，读日志并修复依赖
• 批量处理字幕，生成可交付的 SRT 或视频字幕结果
• 根据术语库和翻译记忆，继续处理同一客户的新文件

这些任务的共同点是：它们不是一句回答，而是一条链路。

聊天入口只是开始。

后面需要文件解析、模型调用、工具执行、失败重试、权限控制、结果下载、日志追踪和继续追问。

LinkGo、OpenClaw、Hermes 和本机沙箱结合起来，就是为了把这条链路尽量连上。

我现在越来越觉得，办公 AI 真正的壁垒不是“谁的回答更漂亮”，而是：

• 能不能读懂真实文件结构
• 能不能安全地操作本机工作区
• 能不能把模型、工具和记忆放在同一条任务线上
• 能不能失败后知道怎么补救
• 能不能最后交付一个用户能打开、能检查、能继续用的结果

这也是 LinkGo 后面会继续强化的方向。

如果你也在做 AI 文件处理或本机智能体，我建议先别急着追“全自动”。先把边界、日志、文件管道和交付结果做扎实。

真正有用的智能体，不是看起来什么都能做。

而是在该做的地方，真的把事情做完。