• 插图由AI生成

OpenClaw 是一个开源、自托管的自主型 Agent 平台，把大模型、消息入口、工具、skills、session 和 memory 连接起来，让自主型 Agent 能在真实环境里处理任务。

现在很多 Agent demo 看起来什么都能做，但一进入真实工作环境，就会遇到三个问题：它能碰哪些数据，能执行哪些动作，出错以后谁负责。

所以讨论 OpenClaw 这类自主型 Agent，不能先问“能做什么”，而要先问“应该放进什么工作现场”。

原型是个人助手和本地工作台。

核心变量是本地环境、高上下文、高权限、单人协作。

延展方向一是低权限服务型 Agent。

变化变量是权限收缩、对外服务。典型形态包括公网咨询机器人、私域专业顾问。

延展方向二是多角色协作型 Agent Team。

变化变量是角色拆分、组织协作。典型形态包括一人公司机器人团队、企业内部 Agent Team。

场景划分的三个维度

OpenClaw 这类自主型 Agent 能进入真实工作环境，场景划分不能只看“能不能调用工具”。

更关键的是三个维度：权限、上下文、协作关系。

这也是它和普通聊天机器人的主要差异：

Chatbot：用户提问，模型回答。 单任务 Agent：围绕一个目标，调用少量工具完成有限任务。 工作台型 Agent：理解复杂目标，管理上下文，调用多类工具，持续推进任务，并接入真实工作现场。

所以，判断这类 Agent 的应用场景，先看三个问题：

原型：个人助手和本地工作台

个人助手和本地工作台，是理解这类自主型 Agent 的直接原型场景。

这个原型的核心变量是：本地环境、高上下文、高权限、单人协作。

个人助手服务一个明确的人，使用这个人的工作环境，处理这个人的连续任务。

个人助手面对的是用户自己的电脑、资料和项目，因此权限可以高于公网产品。但高权限必须满足三个条件：可见、可控、可回滚。

典型任务包括：

个人工作台更容易体现这类 Agent 的价值：

编程场景最典型。代码仓库本身就是结构化上下文，测试、lint、typecheck 能形成反馈闭环。这类 Agent 可以读代码、改文件、跑测试，并根据错误继续修。

办公和科研场景同样成立。一篇论文、一组资料、一份会议纪要、一个写作主题，都可以进入同一个 workspace。这类 Agent 的价值在于持续完成阅读、整理、总结、改写和沉淀。

对更多非开发用户来说，真正高频的不是改代码，而是资料阅读、会议整理、文稿生成、表格分析、项目材料维护和汇报输出。

个人助手的工程边界必须明确：

个人助手的目标，是在受控的本地工作空间里，让这类 Agent 成为可以持续协作的执行单元。

延展方向一：低权限服务型 Agent

把本地高权限收掉，这类 Agent 能力可以被封装成低权限服务型 Agent。

这个方向的变化变量是：权限收缩、对外服务。

低权限服务型 Agent 主要通过 Web、App、小程序或 API 提供服务，在受控边界内理解问题、调用有限工具、给出建议。

常见形态之一是公网咨询机器人，面向注册用户或公众用户，适合职业咨询、学习建议、产品问诊、行业知识问答等场景。

公网咨询机器人的核心是把危险能力关掉：

这类服务通常需要把用户、会话、历史、计费和审计放在自己的后端，Agent runtime 只负责 Agent 能力和活跃 session 上下文。这样既能利用多轮能力，也能保留用户数据主权。具体的 DB 与 session 分工，可以放到后续低权限服务型 Agent 文章里展开。

另一种是私域专业顾问，面向更固定的人群，比如付费社群、小团队客户、长期咨询对象。

私域专业顾问和公网咨询机器人同属低权限服务型 Agent，区别在关系深度：

公网咨询机器人：低权限 + 弱关系 + 多陌生用户 + 偏单次咨询。 私域专业顾问：低权限 + 强关系 + 固定用户群 + 长期服务状态。

私域顾问不一定需要更高的工具权限，但更依赖 memory、profile、服务状态和人工交接。它需要知道用户是谁、历史问过什么、当前处在哪个阶段、之前给过什么建议、有没有人工顾问介入过。

落地重点包括：

延展方向二：多角色协作型 Agent Team

第二个延展方向是拆分角色：把这类 Agent 能力拆成多个角色型 Agent，让它们围绕同一个工作流协作。

这个方向的变化变量是：角色拆分、组织协作。

这种形态既可以是“一人公司机器人团队”，也可以是企业内部 Agent Team。人负责调度，多个角色型 Agent 负责放大组织能力。

常见角色包括：

每个 Agent 有不同职责，也有不同权限。研发 Agent 可以访问代码仓库，但不应该访问客户账单；客服 Agent 可以查看用户问题，但不应该执行数据库修改；项目管理 Agent 可以整理进度和风险，但不应该直接合并代码。

Agent Team 的关键是建立组织结构：

缺少这些设计，多个 Agent 只会变成多个聊天窗口。真正有价值的 Agent Team 必须围绕工作流转：从目标到任务，从任务到产出，从产出到验收，从验收到复盘。

企业 IM 可以作为 Agent Team 的交互入口，但不能只把它当成聊天窗口。

群聊、私聊、线程、项目群、部门群，对应的是不同的工作关系：谁在发起任务，谁能看到上下文，谁有权限触发动作，结果应该沉淀到哪里。

所以企业 IM 接入的关键，不是“能不能回复消息”，而是 session、身份、权限和审计如何绑定。

企业场景最怕“看起来能用，实际上不可控”。Agent Team 的设计必须从身份、权限、上下文和审计开始。

判断一个场景是否适合这类 Agent

自主型 Agent 适合处理高上下文、高工具依赖、需要持续推进的任务。

任务目标简单、流程固定、上下文很少、结果容易用规则判断时，普通聊天、固定脚本或传统后台功能就够了。

一个任务值得交给这类 Agent，通常要同时具备这些特征：

目标复杂度：不是一句问答能结束，需要理解目标和拆解步骤。 上下文依赖：需要读历史、读项目、读文档、读用户状态。 工具依赖：需要搜索、调用 API、读写文件、跑测试或接渠道。 验证难度：结果需要人或系统审核，而不是完全靠模型自说自话。 出错成本：错误可控，能回滚，能人工接管。 权限边界：能明确规定它能碰什么，不能碰什么。

最容易被忽视的是权限边界。

很多 Agent demo 显得很强，是因为 demo 往往默认什么都能做。

真实上线时，问题恰恰在这里：

这类 Agent 的能力必须被放进正确的边界里。

项目上下文、业务系统封装、渠道接入、tools/skills 版本管理也很重要，但它们属于落地工程问题，放到后续文章展开。

结尾

这个系列聚焦真实工作场景，不做 Agent 概念堆叠和工具排行榜。

下一篇先回到原型场景：个人助手和本地工作台，讨论普通用户、复杂业务用户和编程用户，应该如何选择适合自己的个人 Agent 工作台。