最近连续几个产品/硬件 vibe coding 过程，让我对 Human-AI 的人机协作和交互有了更多的实际体验和感受：
一个人类可以通过某种工具同时驾驭多个 Agent；Agent 可以进入一个人的工作流 as smart workmate，也可以进入生活流 as personal helper；再往前一步，Agent 开始原生组织一个人的工作流 as coordinator；甚至原生组织一群人、一个团队的工作流同时 as coordinator、assistant、workmate and employee……太多形态和方式的排列组合，太多在某些具体点上的创新了
比如 raft.build、Tutti、Grok Bot、Town、Instinct、Kimi Mira……我前前后后写了好几个产品研究和 memo，但看得越多反而越来越怀疑，这一大块蛋糕究竟是谁的机会？模型厂、协作平台、初创公司，还是开源工具？最后谁能拿到真正的大结果啊
大家 5 月份还在聊 agent as employee 所谓“原生数字员工”，到了 9 月却隐约有种大厂准备下场结束比赛的感觉。对，说的就是国内办公 Agent 之卷，以及前两天发布的豆包工作伙伴。 Claude Tag 创造的交互范式难道要被豆包后发制人了吗？
AI 行业真是 real 日行千里，3 月我还在惆怅怎么优化接入飞书群聊的 OpenClaw（后来不了了之），半年后的 9 月，一个更底层的版本答案直接舞到了眼前。这也是我看到豆包工作伙伴时最强烈的唏嘘感：那些我曾经尝试手工解决的 Agent 工程问题，正在被大厂封装成组织级产品能力。
而“飞书底座 + 豆包 Agent Runtime”这个二级纠缠进化体，恐怕会在很长一段时间里成为团队/协作类 Agent 创业公司都必须回答的那句：这个飞书和豆包做了，你怎么办？
以下内容来自我和 RabbitT（OpenClaw）的讨论，算是一些阶段性思考和总结，背后可能是一个待验证的更大命题：
当 Agent 从“被人使用的工具”，变成工作流的参与者、协调者甚至组织者，机会的归属便不再只取决于谁先做出一个聪明 Agent，而取决于谁拥有它赖以行动的上下文、权限和正式工作对象。
01.
豆包工作伙伴与“把 OpenClaw 接入飞书群聊”有什么不同
表面效果非常相似：Agent 进入群聊，成员通过 @ 向它委派任务，它读取群上下文并调用工具完成工作。
但自行将 OpenClaw 接进群聊时，仍需人工搭建大量 Harness：
为不同群建立独立 session，避免群聊上下文污染 main session； 单独补充角色 prompt、agent.md、skill 与 memory 规则； 设计群聊、个人和长期记忆之间的读写边界； 配置 @ 触发、主动任务、定时任务与外部工具权限； 明确跨 session 的 handoff、共享状态与正式产物位置。
我们此前已经验证：飞书群聊不是天然的共享大脑，只是另一个 session。真正的协作不能依赖“机器人在群里看见了消息”，而要依赖 task contract、shared state、explicit handoff 与 artifact interface。
豆包工作伙伴的价值，是把这些原本需要 Agent 工程师手工设计的 session routing、memory scope、identity、permission、event trigger 和 artifact flow，封装为组织级产品能力。
最近 vibe coding 时我已经体会到：多个 Agent 能不能协同，关键就是取决于任务是否拆清、状态是否共享、产物是否落在正确位置、失败后谁来接管。豆包只是把我在个人尺度上手工搭建的这套东西，放大到了组织尺度。
我经常向朋友感叹“产品开发问题最终都是组织管理问题！”，which means 很多看起来属于“Agent 智能”的问题，最后决定产品能否稳定成立的，往往还是上下文、权限、状态与交接。
02.
核心的差异还有 memory：共享身份，分层记忆
它不是把团队所有员工的记忆混成一个大脑，也不是每个人各自拥有一个完全无关的 Agent，而是：
一个团队共享的 Agent 身份，背后挂着按人、群、任务和组织分层隔离的上下文与记忆。
可以拆成四层：
共享身份层：团队面对同一个名称、人设、角色、技能、自动化流程和组织身份。 个人层：每个人的私聊、个人偏好及相关记忆原则上按用户隔离，个人会话内容仅本人可见。 协作层：群聊、团队任务、交接资料和共同产物可以成为共享上下文。 权限层：Agent 调取企业资料时仍受当前用户身份和对象权限约束，不会因为 Agent 是共享的，就把甲有权访问的信息泄露给乙。
因此，“团队共同训养一个 Agent”是准确的，但需要限定：
团队共同塑造的是公共人格、工作方法和经过确认的组织知识；个人私聊不会天然汇入一个无边界的公共记忆池。
真正能够成为组织记忆的，通常是被明确写回群聊、文档、多维表格、知识库或其他共享资产的内容。
这背后还有一个很重要的变化：记忆不再只是 Agent 脑内“记住了什么”，而开始成为组织中谁能看见、谁能修改、什么可以被共享、什么必须被隔离的一套治理结构。（5 月 make for agent 那条笔记也有讨论责任链问题）
03.
对比 Claude Tag + Slack，飞书底座带来的六个结构性创新
1. 从消息上下文升级为组织对象图谱
Slack 的原生核心仍是频道、消息和线程，其他工作对象主要通过第三方连接器进入。飞书原生掌握人与组织架构、群聊、文档、会议、日历、任务、OKR 和多维表格，它们共享身份、权限和对象关系。
因此，一句”这个选题下周做”可以继续沿组织对象链执行：
识别选题 → 写入选题库 → 匹配负责人 → 查询忙闲 → 创建日程 → 发出邀请 → 跟踪任务
这不是简单的工具数量优势，而是数据与行动存在于同一张组织图谱中。开发者在飞书上搭 Agent 工作流时，想让它”把讨论结论写进多维表格、给负责人建任务、排进日历”——每一步都要自己写代码去调 API，豆包直接把这条链路变成了原生能力。（打不过真的打不过……
2. 从产生答案升级为产生组织事实
群聊 Agent 最容易成为一个聪明的讨论参与者；飞书原生 Agent 则可以直接改变组织系统中的正式状态：
在多维表格新增一条记录； 修改任务状态和负责人； 创建真实日程并邀请成员； 把讨论转成团队共同编辑的文档； 将确认后的成果重新沉淀进知识库。
核心行动链由此闭合：
Conversation → Decision → Record → Assignment → Schedule
“回答得很好”与”工作真的向前走了”之间，差的正是这些组织事实。这个”最后一公里”才是真正决定工作有没有向前走的分水岭。
3. 组织事件成为 Agent 的感知器官
豆包工作伙伴可以围绕日程变化、文档 @、任务指派和 IM 消息等事件主动工作。它感知的不只是”人说了什么”，还包括”组织状态发生了什么变化”。
主动性因此从”没有被 @ 也会插话”，升级为”在状态变化后准备材料、提示风险或继续执行”。我让妙蛙种子（Claude Code）做过类似的尝试——设置定时任务检查日程变化、文档更新，然后触发后续动作——但每一种事件都要自己轮询和解析，脆弱且维护成本高。当事件系统是平台原生提供的，维护成本就从每个开发者身上转移到了平台。
4. 权限可以深入业务数据内部
Claude Tag 可以控制进入哪些频道、连接哪些工具与代码库；飞书体系还可以继续细化到数据表、字段和记录层，例如只读某些字段、只能编辑本人创建的记录。
这使 Agent 可以被授予有限但真实的业务操作权，更接近员工权限，而不仅是机器人权限。
做过 Agent 权限设计的人都知道，”全开”和”全关”都好做，难的是”这个人能看这几列、能改自己创建的行、不能碰别人的”——这种细粒度控制在自建方案里是巨大的工程量，飞书把它变成了配置项。（打不过真的打不过……
5. 个人 Agent 与团队 Agent 共用同一组织环境
飞书正在同一环境中容纳专属工作伙伴、群聊工作伙伴、专业 Agent、固定 Agent 团队，以及第三方或企业自建 Agent。个人记忆、团队协作与企业治理因此有机会在一套身份和资产体系内完成安全流转。
6. 云端持续运行与本机执行可以衔接
官方描述的架构是：主体在云端 7×24 小时运行；当任务依赖本地文件、工作目录、内网或登录环境时，再通过飞书客户端在授权范围内调用本机执行。
这正是我在自己的 Agent 架构中反复纠结的问题：云端 Agent 跑得起来但碰不到本地文件，本地 Agent 碰得到文件但休眠就没了。两者之间的桥梁，我用 launchd 守护进程勉强搭了一个，踩了无数坑，豆包把”云端认知 + 本地行动”做成了平台级方案。
把这六点放在一起看，豆包工作伙伴的关键不是”飞书里多了一个能干活的字节亲儿子 Agent”，而是 Agent 第一次拥有了一副相对完整的组织身体：它有身份、有感官、有记忆、有权限，也能对真实工作对象采取行动。（这才是 Agent 创业公司梦寐以求的样子吧……
04.
与 Claude Tag 的真实差别
作为开创玩法、珠玉在前的前辈，咱不能把 Claude Tag 简化成“只能在 Slack 里被 @ 的机器人”。Anthropic 官方已经展示了它的频道记忆、工具与代码库连接、未来任务规划、主动分诊，以及从事故告警、读取日志和 runbook，到提交 PR、生成复盘的完整流程。
所以两者不是“一个主动、一个被动”，而是两条不同的架构路线：
Claude Tag：以强 Agent 为中心，向外连接组织工具。
豆包工作伙伴：以组织操作系统为中心，把 Agent 嵌入所有工作对象。
Claude Tag 的优势在模型能力、代码任务、长程执行和开放连接器生态；豆包工作伙伴的优势在组织上下文连续性、原生事件、业务对象写入和治理闭环。
但这里有一个不对称：飞书与豆包同属字节体系，协议共建和集成摩擦趋近于零——双方可以共同设计事件、权限、审批、回滚、审计、计费与企业采购，根本不存在两个公司之间的产品边界。
但 Anthropic 与 Slack 之间这条边界始终存在：Slack 要服务多模型生态，不可能为 Claude 独家重构底层对象模型；Anthropic 也不会只押 Slack 一个入口。这意味着 Claude Tag 的每一步深度集成都需要跨公司谈判，而豆包工作伙伴的每一步深度集成只需要内部排期。长期看，这个结构性差异会越拉越大。
放大看，这俩放一块不应该做产品功能对比，更需要比较”Agent 如何进入组织”的两种世界观：一种相信更强的 Agent 可以通过连接器穿透工具边界；另一种相信组织底座本身应当为 Agent 重构。在中国市场，后者几乎一定赢——因为飞书/钉钉/企微已经是组织数字化的事实底座，Agent 不需要穿透任何边界，它就生在边界里面。
05.
产业判断：谁会拥有“团队 Agent”
通用型组织 Agent 大概率是“模型厂 × 协作平台”的生意，因为底层同时需要模型、持续运行、身份权限、租户隔离、记忆路由、企业治理和分发入口。
产业可以拆成三层：
模型厂卖 Agent Runtime：推理、记忆抽取、长程执行、多 Agent 调度与工具调用。 协作平台卖组织上下文与权限底座：人、群、文档、任务、会议、数据和组织关系。 创业公司卖垂直工作闭环：法律尽调、客服运营、临床研究、供应链排产、活动策划等具备行业判断与验收标准的完整工作。
创业公司的危险区，是做一个”更好用的通用团队 AI 同事壳”，却没有独占数据、工作流和结果闭环。这类产品很容易被模型厂或办公平台的一次原生更新覆盖。
所以，创业公司的机会肯定不会是复制豆包工作伙伴，很可能是：
不卖 Agent 本身，卖 Agent 已经学会完成的一种具体工作。
拿一个我自己做过的例子：深度研究报告。从品类归纳、多语言关键词扫描、竞品池筛选、信源交叉验证、图表生成到 PDF 排版——这条工作流里的行业判断（什么算同赛道、哪些信号值得追、风险怎么定性）不是通用 Agent 能封装的，它需要真正做过调研的人把”品味”写进流程。豆包可以提供组织底座和模型能力，但”这份报告该怎么做才有洞察”给不了。总结来说，垂直闭环的护城河不是技术壁垒，是判断力壁垒。
模型厂负责让 AI 能在组织里活着；协作平台为它提供组织身体；垂直创业公司负责让它在某个行业真正上岗。
所以问题不能被简化理解成“谁会做出最好的 AI 员工”，而是：
谁能定义人与 Agent 共同工作的组织结构？
大厂很可能占据通用底座，但具体工作应该如何被理解、判断和验收，仍然属于真正懂场景的人。模型提供智能，平台提供身体，垂直创造者提供职业、品味与灵魂。
如果通用底座注定属于大厂，那真正值得个体创造者投入的是什么？对于我自己来说，这可能也是连续做了这么多产品、硬件和 Agent 实验以后越来越清晰的一件事：我真正感兴趣的，从来不只是”做一个 AI 工具”，而是在不同尺度上设计人和 Agent 如何相遇、如何分工、如何形成关系，又如何共同把一个模糊念头变成现实中的作品。
这场比赛不会因为大厂做出了通用数字员工就结束。恰恰相反，当通用能力成为基础设施，真正的创造才刚刚开始。
