概念插画：以模型品牌元素为灵感的 AI 实习生角色，表现业务专家的带教过程。
现在看 AI Agent 产品，我习惯先把它们分成两类。一类像 Manus，在云端给 Agent 一个工作环境，把任务交过去，等它返回结果。另一类像 Claw，把 Agent 接进自己的电脑，直接使用手边的文件、工具和工作环境。
沿着这个分法，Hermes、OpenClaw、WorkBuddy 可以放到 Claw 这一侧，Manus、Muse、Grok Bot 可以放到云端这一侧。接下来再做一个 Agent 产品，该选哪边？我会先想清楚用户愿意把什么事情交给它。结合最近几个项目，我更想给业务专家配一位 AI 实习生。专家一边用它完成工作，一边教它判断和处理问题；经过反复验证，再把它带成能够承担明确职责的 AI 正式工。
两种形态，从不同的地方接近用户
这里的 Claw 形态是一个讨论产品的简称，并不表示这些产品有相同的技术实现，或都属于 OpenClaw 生态。它强调的是：Agent 进入用户已有的环境，获得持续工作的上下文。
Manus 形态则强调托管体验。用户交出任务，平台准备执行环境、管理运行过程，再把结果交回来。
截至 2026 年 9 月 28 日，几款产品的公开能力已经让这条边界变得模糊。下面依据官方资料整理，并非逐款实测。
| 产品 | 与这次讨论相关的公开能力 | 本文的观察角度 |
|---|---|---|
| Hermes Agent | 支持本地安装，也可运行在 VPS 和其他远程基础设施上，提供跨会话记忆、技能与定时任务 | 从用户可管理的长期 Agent 环境理解 Claw 形态 |
| OpenClaw | 自托管 Gateway 连接消息入口与 Agent，也支持远程 Gateway 和本地节点 | 工作环境可以分布在多台机器上 |
| WorkBuddy | 桌面办公工作台，可读写本地文件、调用工具并交付工作结果 | Agent 直接进入个人办公现场 |
| Manus | 以云端执行为起点，也通过 Browser Operator 使用用户本地浏览器 | 托管执行逐步连接用户已有环境 |
| Muse | 此处指 Meta 的个人 Agent，运行在专属云端虚拟机中，能在关闭应用后继续工作 | 云端也能承载长期个人上下文 |
| Grok Bot | 在持久化云端电脑上工作，拥有浏览器、文件系统和终端 | 云端 Agent 可以成为持续存在的工作伙伴 |
对应资料：Hermes 文档、OpenClaw 远程 Gateway 与节点、WorkBuddy 产品页、Manus Browser Operator、Meta Muse 发布说明、Grok Bot 文档。
因此，“Claw 是本地、Manus 是云端”适合作为理解起点。继续讨论产品方向时，还得看执行环境由谁管理、上下文能保留多久、用户怎样参与工作。安装了桌面客户端，不代表任务一定在本地执行；Agent 在本地运行，也不代表模型推理和数据处理全部留在本机。
云端省下维护，本地靠近工作现场
Manus 形态最吸引我的地方，是用户不用先搭一套环境。查资料、分析公开数据、制作一份报告，都可以从一个目标开始。任务主要依赖公开信息或用户愿意上传的材料时，云端环境很合适。
托管服务也更容易承接离线后的工作。电脑合上了，任务仍能继续；换到手机，可以查看进度和处理需要决定的事情。平台还可以按任务分配资源，让耗时的工作在后台完成。这些便利依赖具体产品的运行与资源策略，不能从“云端”两个字自动推导出来。
困难通常出现在任务接近真实业务的时候。资料存在某个本地目录，系统只能从内网访问，浏览器里有用户自己的登录状态。把这些条件搬到云端，需要上传、连接、授权和维护。任务执行前，用户可能已经花了不少时间整理输入。
Claw 形态靠近这些东西。项目文件、现成脚本、桌面软件都在眼前，Agent 可以直接接着已有工作往下做。对开发、设计、工程分析以及大量围绕文件展开的办公任务，这种距离很有价值。我之前写的目录工作站，就是把资料、规则和执行方法留在同一个工作目录里。
但本地也把运行责任带给了用户。机器休眠、网络中断、软件升级、权限变化，都可能让任务停下来。Agent 如果和人共用一个桌面，还可能抢焦点、改动正在编辑的文件。开放整个硬盘的权限，远远超过完成一项具体工作所需的范围。
| 要做的工作 | 更适合从哪里起步 | 需要解决的问题 |
|---|---|---|
| 基于公开资料做研究、生成报告 | 云端 | 来源质量、结果核验、运行费用 |
| 整理本地项目、使用桌面专业软件 | 本地 | 文件权限、环境依赖、对人的干扰 |
| 持续跟踪云端业务系统 | 云端或企业托管环境 | 账号授权、业务状态、失败恢复 |
| 同时依赖内网资料和外部信息 | 按步骤组合两者 | 数据边界、任务交接、重复执行 |
我不认为每款产品都应该马上做端云协同。如果用户的全部工作已经能在云端完成，增加本地客户端可能只会增加维护负担。同样，一项围绕本地工程软件的任务，也没有必要为了“云化”先搬走整个工作环境。
给业务专家配一位 AI 实习生
最近回看自己做的招聘、散热仿真、数据库和软件生成项目，我发现它们都在接近一种工作关系：专家表达目标，Agent 使用软件、整理资料、执行操作，专家再检查结果、补充条件和纠正判断。
我想沿着这层关系继续做产品。用户第一次打开它时，得到一位有基础能力、但还不熟悉自己业务的 AI 实习生。它可以先做资料整理、信息提取和结果草稿，遇到不确定的地方拿着依据来问。业务专家在日常使用中带它熟悉岗位，让它逐渐承担更多工作。
这里的专家可以是招聘顾问、散热工程师、数据分析师或软件实施人员，也可以是独立从业者。一个人就可以开始带自己的 AI 实习生，不必先建设一套企业组织和审批系统。
几类项目让我对这个方向有了更具体的想法。下面是产品设想，现有实现还没有证明 Agent 已经具备完整的岗位能力。
| 场景 | AI 实习生先做什么 | 专家在使用中教什么 | 将来可以验证的独立职责 |
|---|---|---|---|
| 招聘 | 整理授权使用的简历，提取岗位相关信息，附上原文依据 | 哪些是必要条件，资料缺失怎样处理，推测与事实怎样区分 | 按已确认口径完成初筛材料和待核实清单，交给招聘人员判断 |
| 散热仿真 | 检查工程、整理参数、准备求解与结果比较 | 工况与设计参数的区别，适用策略，收敛和结果检查方法 | 在已验证的模型与参数范围内执行分析，异常交回工程师 |
| 数据分析 | 读取数据结构，准备查询，解释结果来源 | 指标口径、时间范围、关联关系和异常数据处理 | 在授权数据范围内完成固定分析，并保留查询和核验依据 |
| 软件实施 | 整理变更需求，准备修改，生成预览和检查记录 | 字段变化怎样影响权限、报表、历史数据与打印 | 在指定系统和变更范围内完成修改与验证，交付可验收版本 |
这个比喻也会改变产品界面。用户需要看见它在做什么、依据是什么、哪里拿不准，以及这次纠正会怎样影响下次工作。聊天用来交代任务和讨论，候选人比较表、参数差异和数据结果则帮助专家具体检查。
第一次使用时，也不能把全部带教负担交给专家。产品应当自带最基本的软件连接、任务模板和检查能力，让它先完成一件有用的小事。专家补充的是自己的业务条件和方法。每次都要从头教怎么打开文件、怎么保存结果，很难让人愿意长期带下去。
本地与云端可以服务于同一段带教过程。需要跟着专家使用本机工程文件和专业软件时，Claw 形态比较顺手；经过授权的检索、后台运行和跨设备查看，可以由云端承担。专家更关心的是换了入口之后，之前确认的任务、规则和纠正还能不能接着用。
一边完成工作，一边把带教过程留下来
发现问题、记录修正、换一个任务验证，带教记录才逐步成为可复用的方法。
我希望产品能够让业务沉淀自然发生在使用过程中。专家看到问题时，可以直接说“这里少检查了一项”“这条要求只适用于这个客户”“这种情况先问我”。Agent 根据这些反馈修正当前任务，再整理出值得保留的内容，请专家确认。
例如，招聘顾问发现 Agent 把“简历没有提到某项经验”写成了“没有这项经验”，就纠正它：资料缺失应标成待核实。产品除了修改当前结果，还可以提出一条候选规则，并关联这次出错的例子。专家确认后，再用其他简历检验它是否能正确区分缺失信息和明确不符合。
散热场景里，工程师可能纠正另一种错误：降低输入功率后的温度下降，不能直接计作结构优化收益。这个反馈应当进入参数分类和结果比较的检查方法。下次遇到类似任务，Agent 需要先识别工况是否改变，再决定结果能否放在同一张比较表里。
这些过程留下的业务资产，各自有不同用途。
| 沉淀内容 | 应该留下什么 | 后续怎样使用 |
|---|---|---|
| 业务知识 | 术语、指标含义、来源和适用时间 | 帮助理解新的任务 |
| 工作方法 | 输入要求、操作步骤、工具依赖和结果模板 | 复用已经验证的执行方式 |
| 判断规则 | 适用条件、例外和需要请教专家的情况 | 决定下一步动作与交回人的时机 |
| 案例与反馈 | 原结果、专家修正、修正原因和验收记录 | 检查相同错误是否再次出现 |
| 能力记录 | 验证过的任务范围、版本和失败情况 | 决定哪些工作可以独立交给它 |
这里说的“带会了”，首先可以通过记忆、规则、技能、工具配置和检查案例来实现，不意味着每次对话都会自动训练底层模型。产品必须把这些内容存下来，并在后续任务中正确调用，专家才能感受到带教有了效果。
临时要求也不能直接变成永久规则。某个客户的筛选口径只适用于这个客户，一次工程上的有效调整也未必适用于其他模型。产品需要分清当前任务、客户专属要求和可复用方法，允许专家查看、修改、撤回，并在规则冲突时请人判断。
我也不希望产品把所有交流都原样堆进“记忆”。专家需要能看见这次建议沉淀了什么，为什么值得保留，以及会影响哪些任务。没有经过确认的候选方法，可以留作待验证内容，不能直接扩大执行权限。
随着工作积累，专家手里会多出一套业务资料和方法记录。即使更换模型，已经确认的口径、案例和验收标准也应该能够保留并重新验证。这些资产需要能够导出，才能让专家愿意持续投入带教时间。
AI 正式工要按具体职责转正
我所说的 AI 正式工，是在明确职责、环境和权限范围内，能够稳定完成约定工作的 Agent。它仍然需要报告进度、保留结果依据，并把超出能力范围的问题交给人。
一个招聘 Agent 可以胜任“整理初筛材料”，同时仍在学习“理解新的行业岗位”。一个工程 Agent 可以稳定处理已验证的参数修改，却还不能接手陌生几何模型。转正应当对应一项项职责，产品不能用一个总等级概括全部能力。
带教过程可以逐步推进：
| 阶段 | Agent 怎样工作 | 专家怎样参与 |
|---|---|---|
| 跟着做 | 看示例，整理输入，提出计划和草稿 | 示范方法，指出遗漏与错误 |
| 带着做 | 执行已确认步骤，提交依据和待判断问题 | 检查结果，修正方法，确认可复用内容 |
| 试着独立做 | 处理预先限定的新任务，主动识别例外 | 用事先约定的标准验收，记录返工和干预 |
| 承担固定职责 | 在授权范围内持续执行，遇到例外暂停或交回 | 抽查质量，处理异常，定期复核能力 |
从 AI 实习生到 AI 正式工，应该有专家确认过的能力范围，也有真实任务留下的验收记录。 聊天时间长、保存了很多记忆或成功运行过一次，都不足以说明可以放心委派。
验证时，需要给它一些没有直接教过、但属于同一职责范围的任务，还要包含资料缺失、工具失败和条件冲突的情况。产品既要检查结果是否正确，也要检查它能否发现自己做不了、会不会遗漏必要步骤，以及专家最后花了多少时间检查和返工。
不同岗位的验收标准可以不同。招聘材料看证据和缺失项是否准确；工程任务看修改是否正确、工况是否一致、结果是否有效；数据分析看口径和结果能否核对。标准应当在验证前由专家明确，不能等 Agent 做完以后再为结果调整要求。
独立承担职责之后，权限也只覆盖这项工作。能够整理候选人资料，不代表可以自行联系候选人；能够准备软件修改，不代表可以自行发布。需要对外操作时，沿用用户明确给出的授权范围。
外部软件、业务规则或模型版本发生变化，还需要重新检查相关能力。出现反复失败时，可以把受影响的职责退回需要人工复核的阶段，修订方法后再验证。产品应当保留变化前后的版本，帮助专家定位退步发生在哪里。
商业上，我更想验证用户是否愿意为“越来越少需要反复交代的 AI 同事”持续付费。衡量价值时，要把专家最初的带教投入、日常检查和异常处理一起算进去。如果一直要人陪着，既没有减少重复指导，也没有积累可复用方法，这个培养过程就还没有带来预期收益。
让业务专家参与培养和交付的生态
通过真实任务验收能力，再把积累的方法带到新的专家和工作环境中。
沿着这条路线，业务专家会同时扮演使用者和带教者。他在真实工作中培养自己的 AI 实习生，也可能把经过验证的岗位方法交付给同行，让别人从一个更好的起点开始。
我设想的生态里，开发者提供基础 Agent 能力、软件连接、记忆与验证机制；业务专家带来岗位知识、案例和验收标准；使用者在自己的工作环境里继续适配和反馈；产品运营者负责版本分发、兼容维护和问题追踪。
可以共享的内容，是岗位说明、方法、工具配置、适用边界和经授权的验证案例。客户数据、账号权限和某个组织的私有规则，需要单独处理。复制一个培养好的 Agent，也需要重新配置访问权限，并在新环境里验证。
因此，一位专家带出的 AI 正式工，进入另一位专家的工作环境时，可以从适配期开始。对方补充自己的口径和例外，通过本地任务验收后，再决定让它承担哪些职责。专业经验可以复用，原来的验收结论不能无限延伸到新场景。
软件生成也可以成为培养过程的一部分。专家发现现有表格或操作页面不适合工作，就让 Agent 准备修改，生成预览、检查旧功能和数据变化，再确认是否使用。这样，业务方法的变化也能带动工作界面的变化。
专家投入带教时间，需要有持续收益。最直接的收益，是自己的工作更容易完成；进一步可能是岗位方法授权、适配服务和持续维护收入。产品需要保留贡献者、版本和适用范围，让专家能够说明自己交付了什么，也让使用者知道遇到问题该找谁。
我不会一开始就做一个列着许多“AI 员工”的市场。第一步可以很小：让一位专家带出能承担一项职责的 Agent，再让另一位专家在自己的环境里接着使用。观察还要补多少知识、改多少方法、花多少支持时间，才能判断它适合标准化交付，还是需要继续作为专业服务经营。
对我现有的项目来说，招聘、散热、数据分析和软件实施都可以成为这种培养过程的试验场。先选有真实任务和愿意参与带教的人，记录 AI 实习生反复犯的错误、专家的修正，以及后续独立完成的情况。已有的运行平台和协作能力，用来解决这个过程中的具体问题。
我接下来最想验证的，是专家第二次、第三次把同类工作交给它时，是否确实少解释了一些、少修改了一些。等到一项职责能稳定交出去，再把这段培养过程整理出来，交给下一位专家继续验证。