Workspace Agents 与企业工作流

企业工作流 Agent 正在从概念验证走向生产级部署。已收录的来源分别从数据仓库治理（Hermes Agent，得物）、组织架构编排（AgentTeams/HiClaw，承吉）、小团队自动化（WorkBuddy，李伟山）、管理分析赋能（吕昭波）和人才结构调整（叶小钗）五个维度给出了具体实现。前两轮聚焦于”Agent 如何工作”，本轮新来源将视野扩展到”谁使用 Agent、用来做什么、怎么判断好坏”——从执行层推到了人机分工、岗位结构和战略决策层。 [[raw/2026-04-24/金色传说大聪明/OpenAI 发布 Workspace Agents，接替 GPTs.md|来源: OpenAI 发布 Workspace Agents，接替 GPTs.md]] [[raw/2026-04-26/宇宙编辑部/YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md|来源: YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md]] [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]] [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]] [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]] [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]] [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: AI Coding赋能管理人员.md]]

从企业流程到小团队运营

Workspace Agents 代表的是组织级任务承接：请求分流、反馈路由、周报生成、内部指标处理。 [[raw/2026-04-24/金色传说大聪明/OpenAI 发布 Workspace Agents，接替 GPTs.md|来源: OpenAI 发布 Workspace Agents，接替 GPTs.md]]
OPC 文章则把同一思路挪到更小单位：AI 不只是提高单人效率，而是帮助一个人搭起完整运营面。 [[raw/2026-04-26/宇宙编辑部/YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md|来源: YC 合伙人：如何利用 AI，从零建立一家出色的 OPC.md]]
WorkBuddy 则把同一原则推到个人知识工作者层面：每日早 8 点自动推送 AI 行业早报（24 条资讯、5 大板块），人工参与度为零，规则写死后稳定运行数月。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]

工作流接管的真正难点

企业经验与一人公司经验都在指向同一个问题：自动化不是目的，真正重要的是减少中断、减少上下文丢失、减少重复接力。 [[raw/2026-04-30/问答/AI 工作流最重要的不是更自动化，而是不打断人.md|来源: AI 工作流最重要的不是更自动化，而是不打断人.md]] [[raw/2026-04-27/孟健的AI编程认知/程序员创业半年：顺的事、不顺的事，和我一直没想清楚的事.md|来源: 程序员创业半年：顺的事、不顺的事，和我一直没想清楚的事.md]]
这也是为什么 Claude Code、OpenClaw、Superpowers 和 Workspace Agents 最终都会汇到”治理工作流”这件事上。 [[raw/2026-04-30/AI兴观点/你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md|来源: 你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md]]
WorkBuddy 的实践进一步揭示了一个更基础的原则：给 AI 的输入质量直接决定产出质量。“知识库先行”——不给 AI 空白 prompt，先喂上下文资料——是提高工作流可靠性的最低成本手段，比编排更复杂架构更优先。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]] [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: AI Coding赋能管理人员.md]]

架构模式分化：单 Agent 编排 vs 多 Agent 平台

当前企业 Agent 架构出现了三条不同的路线，未形成收敛共识：

单 Agent + 能力模块: Hermes Agent 刻意不走多 Agent 群聊路线，选择单 Agent 编排 + 多个能力模块 + 看板确认点的架构。核心理由是数据仓库场景需要确定性流程，多 Agent 的自由对话反而增加不确定性。每个需求经历”录入 → 设计 → 演练 → 审核 → 交付”的状态机，每个阶段指定人类责任人。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]
多 Agent 编排即组织架构: AgentTeams（HiClaw）是一个独立于 Agent 运行时的编排平面——类比 Kubernetes 之于容器运行时。其核心抽象是 CRD：Manager（平台）、Team（业务单元）、Worker（执行单元）、Human（真人）。组织层级直接映射为 CRD 层次：TeamAdmin（真人员工）→ TeamLeader（编排 Agent）→ Workers（执行 Agent）。Manager 只做平台操作，不进入业务房间。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]
单 Agent + Hooks + 专有 Sub-agent: 扶苏的实践路线，强调 Agent 自我约束而非平台管控。
小团队分层工具链: WorkBuddy 代表另一种务实路线——不追求多 Agent 编排，而是在工具层面做精确分工：Codex/Claude Code 专攻纯编码（直接操作代码库），WorkBuddy 处理一切需要理解、记忆和信息管理的任务。团队规模不大时，这种分层比多 Agent 编排更为直接可行。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]

矛盾：Multi-agent coordination should be handled by a shared runtime (OpenClaw/CoPaw) vs Agent runtime and orchestration should be separate layers — AgentTeams works ABOVE any runtime, analogous to Kubernetes above container runtimes [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

矛盾：OpenClaw is the dominant multi-agent platform for enterprise workflow automation vs Hermes was chosen over OpenClaw specifically because OpenClaw lacks persistent memory — “close the window and it forgets” was unacceptable for data warehouse scenarios requiring repeated historical recall [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]

未见收敛说明架构选择高度依赖场景，不存在普适最佳实践。关键区分维度包括流程确定性要求、组织层级复杂度、运行时独立性需求以及团队规模。

生产级治理机制

生产部署中涌现出四个关键治理设计：

三闸门（Hermes）

每个生产级操作必须通过三道独立闸门：

事实来源门：操作依据必须来自可信源，证据需可追溯
演练门：在仿真环境中验证通过，系统级模拟通过后才放行
责任门：真人确认后才执行操作任一闸门未通过则阻断生产写入。操作通过结构化工具接口封装为参数化、可审计、可预览的命令，而非页面级交互。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]

看板确认点（Hermes）

状态机中每个阶段都设定人类责任人，用看板可视化流程推进。这不是审批流而是确认点——Agent 推进工作，人类在每个关键决策点做最终确认。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]

人即一等公民（AgentTeams）

AgentTeams 将 Human 作为一等 CRD，人与 Agent 共享同一 Matrix 通信房间。权限模型分三级：

L1 Admin：平台管理员
L2 Team：团队管理者
L3 Worker：执行者三级权限直接映射到 Matrix 房间访问控制。权限走代码路径（AI Gateway 进行消费者凭证管理），不依赖 Agent 的理解和遵从。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

凭证收敛（AgentTeams）

AI Gateway（Higress）持有所有真实凭证，每个 Worker 获得一个可吊销的 Consumer Token，配合 per-route 的 allowedConsumers 授权策略。这一设计解决了多 Agent 环境中凭证扩散的安全隐患。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

规则收敛（WorkBuddy）

李伟山的 WorkBuddy 实践从另一个角度实现了操作性治理：多项强制性规则（代码回答必须带文件路径、不许擅自改测试、技术决策必须给出理由、输出先经质量检查）共同构成规则屏障。与 Hermes 的三闸门和 AgentTeams 的 CRD 权限形成互补——前者走人类对提示词的理解和遵从，后者走代码执行路径。“规则越死出活越稳”这一经验规律从 coding 场景证明了治理机制确定性的价值。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]

矛盾：趋势方向是减少人工介入、走向全自动化 vs Human 应是多 Agent 系统中的一等公民——Agent 与 Human 必须在同一通信空间，有明确的权限层级；把人排除出回路是危险的 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

知识库先行与固化专家：WorkBuddy 的自动化实践

李伟山通过 WorkBuddy 展示了另一种企业工作流自动化路径——不依赖复杂架构，而是靠三条协作原则驱动：

知识库先行：不给 AI 空白 prompt，先喂上下文资料。AI 产出质量直接取决于输入质量。10 分钟生成 17500 字 Codex 教程的生产案例验证了这一原则的有效性。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]
固化专家模块：将反复使用的工作流封装为”自定义专家”——一次定义、一键召唤，不需要每次都重新描述需求。这与 Hermes 的规则资产化逻辑一致，但粒度更粗、更面向业务场景。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]
工具精确分工：Codex/Claude Code 专攻编码，WorkBuddy 处理理解/记忆/信息管理类任务。这种分层比多 Agent 编排更轻量，适合小团队。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]

AI 赋能管理分析：从战略思考到结构化产出

吕昭波将企业工作流 AI 化从执行层推向了战略决策层。核心原则：管理者负责判断，AI 负责结构化——管理者提供方向和质量判断，AI 将模糊思考转化为可执行的结构化产出。 [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: AI Coding赋能管理人员.md]]

AI 对四种管理分析工具的赋能路径各有不同：

商业画布：AI 输出可验证假设清单、竞品对比矩阵（按九个模块对齐并标注信息可信度）、不同受众版本的一页纸决策简报
SWOT 分析：核心价值在交叉策略矩阵（SO/ST/WO/WT）而非罗列，AI 还可充当”反向提问者”逼迫思考灰色地带
五力模型：AI 生成结构化信息采集模板（针对每一力拆出具体数据问题）和 2-3 种行业变化场景的动态推演
平衡计分卡：自然语言战略目标→四维度可度量指标体系（含数据来源和采集频率），以及季度复盘模板

统一模式的关键原则是**“输出直接进工作流”**——画布分析出战略会议议程，SWOT 交叉策略出 OKR 输入，平衡计分卡出季度考核框架。AI 产出不是终点，而是下一环节的起点。 [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: AI Coding赋能管理人员.md]]

💡 新洞见：输入质量决定产出质量——给 AI 说”技术好”只能返回废话，给”比竞品快 40% 因自研调度引擎”就能产出有价值分析。这同 WorkBuddy 的”知识库先行”原则完全一致，是一条跨场景的普适规律。

AI 时代的信息不对称与红利格局

叶小钗从人力资源和求职市场角度揭示了企业 AI 落地的独特矛盾：进入门槛高但 Demo 门槛低。多数企业区分不了生产级 AI 项目和 Demo 的区别，求职者可以利用这一信息差红利。当前行业”及格线以上的人不占 10%“，企业在招聘侧有大量走展空间。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

矛盾：AI 行业门槛很高、普通求职者应该谨慎入场 vs 叶小钗认为信息差极大、鱼目混珠、现阶段进入 AI 行业有红利来自 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

企业普遍经历四个 AI 认知阶段：什么都能做 → 什么都不能做 → 这个可以做 → 为什么不能 AI 做。这一认知演进直接影响了企业对 Agent 工作流的采用决策和预算分配——处于”什么都能做 / 什么都不能做”阶段的企业最容易踩坑：要么花钱买 Demo，要么因一次失败全面否定 Agent 价值。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

💡 新洞见：竞争力 = 专业能力 × AI 工具 × 项目作品 × 知识表达这一四维公式将人才竞争力从加法关系重构为乘法关系——AI 工具使用能力、项目经验积累和知识表达能力共同构成乘数效应，意味着任一项为零则整体归零。

岗位融合与人才竞争力重构

叶小钗提出三大 AI 原生红利岗位，重新定义了企业 Agent 化进程中的人才结构：

AI 全栈工程师：岗位融合趋势——不再区分前后端和架构师，也不区分 Java/PHP/JS 等语言，岗位界限消失
FDE 前端部署工程师：现场交付复杂度高但工资高，作为独立岗位有清晰的业务价值定位
AI 产品经理：工作范围显著扩大，需要对技术和业务有双重理解

矛盾：全栈工程师是 AI 时代的效率最优解（Half-Stack 反驳中的隐式前提） vs 叶小钗认为以后不再区分前后端和架构师，也不区分 Java/PHP/JS 等语言，岗位融合形成 AI 全栈工程师来自 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

人机分工的共识与分歧

多来源共同指向”人负责判断、AI 负责执行”的分工共识，但其”判断”的定义维度各不相同：

来源	判断的内涵	适用场景
吕昭波	战略方向与输入质量	管理分析工具
叶小钗	行业知识与岗位选择	人才市场
李伟山	输入质量与规则制定	知识生产工作流
Hermes	责任确认与风险判断	生产数据操作
AgentTeams	权限层级与决策权	组织级编排

这组多维度共同构成企业 Agent 化中人机分工的全景——“判断”在不同场景下意味着不同的事物，不能简化为单一口号。共同规律是：AI 当前最佳角色是将人类模糊的思考/输入转化为结构化、可执行的产出。

记忆分层与知识资产化

Hermes Agent 的持久记忆架构是其独立于 OpenClaw 构建的关键理由——“关掉窗口就忘记”在生产场景不可接受：

短期记忆：当前会话上下文
中期记忆：交互历史记录
长期记忆：治理内容、决策记录
技能库：可复用的自动化技能包

实现底座是本地 SQLite + FTS5 全文搜索。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]

最关键的机制是 规则资产化（Rule Assetization）：临时信息留在当前会话，可复用模式沉淀为规则包，治理性内容进入长期记忆。下次遇到类似请求时，Agent 自动触发证据搜集和风险提示。判定哪些信息值得记住的标准是”可复用性”——不重复记忆一次性内容，只将对未来有价值的模式持久化。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]]

WorkBuddy 的”固化专家模块”从另一个角度实现了知识资产化——将反复使用的工作流封装为可一键召唤的专家，不需要每次都重新描述需求。这与规则资产化的逻辑一致，但粒度更粗、更面向业务场景。 [[raw/2026-06-18/腾讯云开发者/20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md|来源: 20年架构老兵的AI探索，让WorkBuddy帮你超越身边的人.md]]

💡 新洞见：规则资产化定义了一个实用性的记忆治理策略——基于可复用性判断”记住什么”，这是多数 Agent 记忆方案缺失的维度。

AI Native 的组织图谱

AgentTeams 提出了一个完整的 AI Native 类比框架：AI Native = 以 Agent 为一等公民设计的系统，类比 Cloud Native 以容器为一等公民。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

Cloud Native 概念	AI Native 对应
容器 (Container)	Agent
Pod	Worker（执行单元）
Service Mesh	Matrix 通信平面
Ingress	AI Gateway（Higress 凭证收敛）
kube-controller	hiclaw-controller（编排控制器）

AgentTeams 明确解决三类核心问题：

可复制性：团队模板化，新建 Agent 团队即部署一组 CRD
可治理性：权限策略走代码路径，不依赖 Agent 对提示词的理解和遵从
可演化性：运行时无关——替换底层的 OpenClaw 为 CoPaw 无需变更编排层

生产验证数据：15 个 Agent × 4 个 AI Native 场景（产品研发、告警排障、开源流水线、商业智能），告警到解决周期从半天缩短到 6 分钟。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]]

叶小钗的岗位融合分析和企业 AI 认知四阶段从”人”的维度补充了这一图谱——AI Native 不仅是技术架构命题，也是组织设计和人才结构的命题。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

企业流程摩擦是真正的瓶颈

已收录来源独立印证同一个结论：组织流程（审批、合规、评审周期）——而非 AI 能力——才是企业 Agent 落地的真正约束瓶颈。“AI 写代码 5 分钟，过 7 道审批走 5 天”这个矛盾普遍存在。Hermes 的三闸门和 AgentTeams 的 CRD 权限模型本质上是同一个应对策略：用结构化的治理机制将组织流程纳入 Agent 系统的设计边界，而不是试图绕过它们。

叶小钗从企业 AI 认知成熟度的角度补充了这一论点：处于”什么都能做 / 什么都不能做”阶段的企业最容易踩坑——要么花钱买 Demo，要么因一次失败全面否定 Agent 价值。企业在招聘和供应商选型阶段的信息不对称进一步放大了这一摩擦。 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三条路.md|来源: FDE、AI 产品经理、AI 工程师.md]]

同时，所有实践路线都采用 Brownfield-first 思维——针对现有代码库和工作流做增量改造，而非从零建设。Hermes 构建于现有数仓工作流之上，AgentTeams 接入现有告警和研发流程，吕昭波的分析方法也是嵌入现有管理工具（画布/SWOT/五力/平衡计分卡）而非另起炉灶。这个取向说明纯绿地的 AI 时代已经结束。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md]] [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md]] [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: AI Coding赋能管理人员.md]]

2026-07 更新：WorkBuddy 专家模式与公司 OS

WorkBuddy 新批次资料把 Workspace Agents 的产品化形态讲得更具体：规则、专家 Prompt、Skills、MCP、Sub-Agents、Memory、工作模式、结果呈现、自动化和连接状态共同组成一个 AI Harness，而不是一堆聊天窗口。[[raw/2026-06-29/Jameszyh/WorkBuddy专家模式底层原理：从Prompt到AI Harness.md|来源: WorkBuddy 专家模式]] [[raw/2026-06-29/Jameszyh/WorkBuddy专家模式底层原理：从Prompt到AI Harness 2.md|来源: WorkBuddy 专家模式2]]

专家团产品化了多 Agent 协作：WorkBuddy 专家团采用主 Agent + 成员 + workspace + workflow + checks 的结构，成员不直接互聊，由 host 分派、整合和验收。这比”群聊式 Agent”更接近可治理工作流：上下文归属、任务边界、结果合并都更明确。[[raw/2026-07-01/叶小钗/WorkBuddy专家团提示词全曝光：多Agent协作原来是这样产品化的.md|来源: WorkBuddy 专家团]]

公司 OS 的最小入口不是平台，而是烦人的重复流程：Laurel/WorkBuddy/增长团队资料共同指向一条路径：先找一个高频、重复、有明确输入输出和反馈信号的流程，把上下文、权限、工具和质量门禁固化，再逐步扩展为公司操作系统。平台先行会变成空架子。[[raw/2026-06-28/Capihom/Laurel CPO：如何用Claude Code搭建一套公司操作系统丨Aakash Gupta.md|来源: 公司操作系统]] [[raw/2026-06-27/Capihom/Clay AI 负责人：增长团队开始像工程团队一样跑 Agent丨LangChain丨Lan.md|来源: 增长团队跑 Agent]]

从可编程工作台到开箱即用智能同事：王正强的测评把 WorkBuddy 放在 OpenClaw 普及后的产品化脉络里：OpenClaw 解决”能执行”，但安装和技能配置门槛高；WorkBuddy 则通过 Craft/Plan/Ask 三模式、三层记忆、技能市场、多 Agent 协作、自动化调度、安全沙箱和本土协作连接器，把执行型 Agent 推向普通知识工作者。这个变化说明 Workspace Agent 的关键竞争点已经从”有没有工具调用”转向”普通用户能否安全地给任务、看计划、收结果”。[[raw/2026-07-03/王正强/架构师深度测评WorkBuddy：办公Agent的新范式已来！.md|来源: WorkBuddy 测评]]

Claude Co-work 与 Live Artifacts 把个人数据源变成可刷新工作界面：Felix Rieseberg 的 How I AI 分享展示了另一条 Workspace Agent 路线：Claude Co-work/Chrome/桌面端不是统一成一个终极入口，而是按快速问答、深度工作、工程工作分流。关键动作是把任务往上抽一层：不是让 AI 替人点鼠标，而是让它读取邮件、日历、房屋文件、购买记录、Slack/Twitter 私信等真实上下文，生成可交互的小工具、仪表盘或承诺追踪器。Live Artifacts 的价值在于同一授权连接可刷新数据，让报告、Pitch Deck、日报和内部看板从静态文件变成持续更新的工作界面。[[raw/2026-07-03/Capihom/Anthropic 工程师：他们到底怎么用 Claude 工作丨How I AI.md|来源: Felix How I AI]]

这篇还补充了两个产品设计判断：其一，模型选择取决于问题清晰度，明确输入输出的执行任务用 Sonnet 足够，连”到底要问什么”都没想清时才让 Opus 先重构问题；其二，Agent 权限不必只做成弹窗，可以是实体按钮、审批队列、dry run、日志摘要或后台状态。好的人机界面应让人放心离开屏幕，只在需要判断、授权或纠偏时回来。

Claude Cowork 的 Skills + Projects 分工：Ruben Hassid 的 X 长文给 Workspace Agents 补了一个面向非代码工作者的产品化视角。Cowork 不是普通聊天，而是多 Claude 会话协同；旧式”文件夹 + about-me 文件”容易上下文泄漏和维护失败，更务实的分工是：Skill 表示可教学、可复用的能力；Project 表示具体客户/活动/上下文空间。Skills 可以在 Projects 内使用，团队也可以共享 Projects 和 Skills。[[raw/X/@rubenhassid/How to learn 80% of Claude Cowork in <20 minutes 如何在20分钟内掌握Claude Cowork的80%功能：.md|来源: Claude Cowork Skills Projects]]

这篇还给出几个边界：全局设置和通用说明越少越好，重复能力做 Skill，重复项目做 Project；Chat 适合快速问答和改写，Claude Code 适合软件交付，Cowork 适合文档形态产物（deck、分析、客户工作）。企业 onboarding 场景可用共享 Project 承载公司资料，再配 /answer-onboarding Skill 要求新人先给出可能答案再提问，把”问人”变成”先用组织知识找答案，再请求确认”。[[raw/X/@rubenhassid/How to learn 80% of Claude Cowork in <20 minutes 如何在20分钟内掌握Claude Cowork的80%功能：.md|来源: Claude Cowork onboarding]]

从个人 Claude 到团队共享 Harness：另一个 X 来源把 Claude Tag/组织级 Claude 描述成共享身份、共享连接器、共享技能和共享上下文的转向。好处是新人 Day 1 就能使用团队成熟 harness，频道里的 Claude 能汇总事故讨论、复盘长线程和主动监控实验；风险是共享配置出错会影响全队，主动提醒也可能变成通知噪音。结论仍是：组织级 Agent 不是”每个人一套 prompt”，而是需要像内部基础设施一样维护共享 harness。[[raw/X/@freeman1266/从每人一套 Claude 到团队共享一个 Harness.md|来源: 团队共享 Harness]]