企业里的 Agent，到底该长成什么样

今天飞书在北京发布了新版豆包工作伙伴，你可以配一个 Agent 拉进工作群，所有人 @ 它派活。三个月前，Anthropic 的 Claude Tag 在 Slack 上做了形态相似的事。

两边隔着太平洋，做出来的东西看着像，但在几个关键地方选了不同的路。

对做 Agent 的人来说，这两个产品本身不重要，重要的是它们把一个问题摆到了台面上：一个 Agent 要进到公司里跟人一起干活，它到底该长成什么样？

这个问题现在没有标准答案。但有六个子问题，任何认真做这件事的团队迟早都得回答。

一、它是一个，还是一群

这是形态设计上第一个分岔。

一种做法是单体：你 @ 它，它读完上下文，自己判断该干什么，自己干完回你。

另一种是编排：接了活自己拆开，派给多个 Agent 并行处理，还能固定编队，按调度规则分工，比如一个负责生产、一个负责检查。

这两种设计对应的是对「企业任务长什么样」的不同理解。

我的判断是，编排形态迟早会成为主流，因为企业里的活本来就是多角色的。

一份方案要人写、要人审、要人批，这不是流程繁琐，这是责任分散的必要设计。让同一个上下文既生产又检查，等于让一个人自己批自己的方案。做自动化流程时最容易出问题的地方就在这儿，模型会倾向于认可自己刚写出来的东西。

但编排带来一个新问题，而且现在没人回答：编排本身谁来管？

谁决定编几个队、怎么分工？一个任务被拆成五个子任务，其中第三个出错了，是队长拆错了，还是队员干错了？企业里这种事有现成答案，因为带队的人要担责。换成 Agent 编队，这条链子是断的。

二、它能摸到哪儿

第二个问题是边界，这个更偏技术层面。

一种设计是活在协作平台里，读消息、写文档、调 API，但够不到你的本机。

另一种是云端常驻加本地执行：主体在云端持续运行，需要动本地文件、工作目录、内网或者已登录环境时，通过客户端下到用户这台机器上执行，文件留在本地。

能不能摸到本机，是「信息类 Agent」和「执行类 Agent」的分界线。

企业里大量的活卡在本地：内网系统没有公网接口、业务后台需要已登录的浏览器会话、文件散在个人电脑上。够不到这些，Agent 能做的就只有整理信息、起草文稿这一类，干不了落地执行。

但这也是风险最集中的地方。一个云端的东西能操作你本机，边界怎么划？目前能看到的约束是三条：在用户授权范围内、访问受权限策略约束、文件始终留在本地。

这三条都是必要的。够不够，要看具体实现，也要看企业自己怎么配。我的建议是把这一条当成采购时的必问项，别等出事再查。

三、它该主动到什么程度

第三个问题最微妙。

被动的 Agent 很好做：你喊它才动。难的是主动，它得自己判断什么时候该开口、什么时候该动手。

这里有个细节值得说。Claude Tag 早期用一个轻量分类器逐条判断「这条消息要不要回」，后来把分类器整个移除了，改成让模型读频道完整上下文，加上记忆和既定指令，在四个动作里选一个：直接回复、在线程里展开工作、并入已有的工作流，或者保持沉默。

按 Anthropic 的说法，这个改动让未经提示的发言减少了约 45%。

「保持沉默」被列为四个动作之一，这是我在这两个产品里看到的最有分量的一个设计决定。

一个会主动说话的东西，价值不在于它能说多少，在于它知道什么时候不说。而 45% 这个数字反过来说明：第一版做得太吵了。

这是所有做主动式 Agent 的团队都会踩的坑。刚上线时会觉得「它主动提醒我了，真聪明」，两周之后就变成群里的噪音源，然后大家开始忽略它，最后把它移出群聊。

决定主动性上限的是人的容忍度，不是模型能力。这个上限比大多数人以为的低得多。

四、模型该不该是可替换件

第四个问题到了规划层面。

一种做法是模型固定，@ 的是谁，底下烧的就是谁，管理员能管花多少钱，管不了换成谁。

另一种是模型可换。飞书这边的做法是：平台预置多家主流模型开箱即用，token 消耗平台的 AI 额度；也可以接入自己在模型厂商开通的 API Key 替换掉内置模型，这时模型费用直接付给模型厂商，不再消耗平台额度，但产物与工具费用仍按平台标准计费。支持范围限定在兼容 OpenAI 接口、且支持 Function Calling 的国内主流模型。

这个差别暴露的是两家对「什么是自己的核心资产」的判断。

模型就是全部身家的那一方，不可能让你换。资产是工作现场的那一方，把模型做成可替换件毫无损失，因为「产物与工具费用仍按平台标准计费」这句留在那儿：你人还在这个平台里，活还是用它的文档、表格、日历干的，产出也写回它的系统。

对企业采购方，这里有个容易误判的地方。模型可换听起来是「避免被锁定」，但锁定点只是从模型层移到了数据和工作流层。你换掉模型那天会发现，真正搬不走的是几年积累的文档、表格和流程。

这个转移对你是好是坏，取决于你更怕哪一种锁定。我的看法是，模型锁定是可逆的，数据和工作流锁定基本不可逆。所以「能换模型」这件事的实际价值，比它听起来小。

五、管控和自主是同一个跷跷板

第五个问题，产品设计上绕不过去。

两边的管控颗粒度差得很远。一边是八大类，包含智能体管理、模型管理、技能审核与下架、可用范围配置、网络访问出口管控、敏感操作管控加策略日志。另一边公开说明里是三项：指定哪些频道和工具可访问、设置 token 花费上限、查看全量操作日志含每个任务的发起人。

差异首先反映的是市场要求。国内企业采购这类系统，管控清单是要过会的，出口管控、操作审计、权限粒度这些是及格线。

但更值得想的是它的代价。

管得越细，Agent 能自己撒开手干的空间就越小。一个每一步敏感操作都要走策略审批的 Agent，和一个能给自己排期、跨天自主推进项目的 Agent，是两种产品，不可能同时做到。

这是同一根跷跷板的两头。而现在几乎没有企业认真讨论过自己要坐在哪一端，大多数是「管控按最严的配，然后抱怨 Agent 不好用」。

六、它在组织里算什么

最后一个问题最难，也最少被提。

看现在的产品形态，Agent 已经有了这些东西：名字、职责范围、权限、成本（管理后台能按 Agent 看消耗）、操作日志。

这几样凑一起，跟 HR 系统里一条员工记录的字段已经差不多了。

差两样。

第一样是考核。现在没有哪家产品能回答「这个 Agent 这个月干得怎么样、值不值它烧掉的钱」。成本数据有了，产出数据没有。等这个问题被认真回答的那天，Agent 才算真的进了组织。

第二样是责任。

这个得展开说。你把一个 Agent 拉进群，它有权限读文档、改表格、调业务系统、往外发消息。它总有一天会干错一件事：改错一个数、发错一个人、把不该同步的东西同步出去。

那一刻，责任在哪儿？

两边给的答案本质上是同一个：可追溯。一边是全量操作日志，连带记录每个任务是谁发起的；另一边是操作留痕、权限严格跟随用户账号。

但可追溯解决的是取证，不解决归责。

追溯到「张三 @ 了它」之后呢？责任有三种落法，对应三种完全不同的组织逻辑：

落在调用者身上。谁 @ 的谁负责。问题是他可能只说了一句「帮我把这个月的数据整理一下」，剩下全是 Agent 自己决定的。按这个逻辑，以后大家 @ 它之前会先掂量一下。

落在配置者身上。谁把这个 Agent 配出来、给了它这些权限，谁负责。问题是配置者不可能预见所有用法。按这个逻辑，以后配 Agent 的人会极其保守。

落在批准引入的人身上。这本质上是把它当成一次管理决策，出了事算决策风险。这个逻辑最接近企业现有的制度，但意味着每次扩权限都要走一遍审批。

这三种分法我自己倾向第三种，因为它跟现有的责任体系能接上。但无论选哪种，都得提前选，不能等第一次出事再临时决定。

现实是大部分公司会等到出事之后才开始写这条规则。而第一次出事的时候，最可能发生的是所有人都去查日志、证明不是自己的问题，然后把 Agent 停掉。

往后会怎么走

第一，形态上会收敛到「编队 + 可下到本地」。单体 Agent 做不了多角色任务，够不到本地的做不了执行类任务。这两条是企业场景的硬需求，跟产品偏好无关。

第二，主动性会先过冲再回调。所有产品第一版都会做得太吵，然后被用户教育回来。那个 45% 是已经回调过一次的结果，后面还会有更多次。

第三，界面层的争夺会比模型层激烈。模型正在变成可替换件，协作平台不会。谁占住工作现场，谁就有资格决定 Agent 用什么模型、能摸到哪些数据。

第四，责任规则会是最后一块补上的，而且会由第一批事故推动，不会由产品文档推动。这块现在是真空，产品方也不可能替企业回答。

第五，这套东西很难长到微信群里。能做「Agent 当同事」，靠的是群连着的组织架构、文档、审批、日历、业务系统和跟着账号走的权限。微信群连着的是关系。在微信群里放一个 Agent，能做的顶多是查天气、发提醒、做个接龙统计。企业微信是另一回事，那才是同一个场子。

最后

这六个问题里，前四个是产品和技术问题，有明确的解法路径，只是时间早晚。

后两个是组织问题，没有产品能替你解决。给 Agent 定身份、定考核、定责任，这些事必须由用这套东西的公司自己决定。

而从产品形态看，技术那一侧跑得比制度快得多。等到大部分公司开始认真想责任怎么划的时候，Agent 恐怕已经在群里待了半年了。

几句边界

文中涉及的产品能力，均以两家各自官方文档和公告的表述为准。管控部分用的是官方文档的章节层级，没有展开每一项的具体实现。

责任那部分引用的用户协议是主产品协议，不是企业版产品的专门协议，实际适用条款以企业签署的版本为准。

两个产品都在快速迭代，形态和条款随时会改。上面的判断基于当前公开信息，不构成对任何一方的推荐或评价。