返回课程目录

第 21 课  企业 Agent

从个人助手走向组织协作,理解共享 Agent 的价值、架构与治理挑战。

预计 25 分钟  ·  系列:从 0 到 1 设计一个 Agent

本课要点

  • 认识企业 Agent,理解组织协作的新形态
  • 看懂共享 Agent 如何连接员工、知识、系统、流程与权限治理
  • 通过 Every、Actively、Dust 的实践分析价值与落地挑战
企业 Agent 连接员工与团队、协作空间、知识与记忆、业务系统、业务流程及治理控制的关系图
企业 Agent 关系图 · 点击图片查看原图

企业 Agent:从个人助手走向组织协作

2026 年 10 月,Agent在C端和 B端出现不同的走向,一方面几家前沿AI公司竞相推出自己的个人Agent产品,另一方面几家服务企业的科技公司几乎同时也提出了企业Agent的概念,后者认为:AI Agent 的下一步发展方向,可能是从服务个人走向服务整个组织。

说实话 我觉得今年AI界,造概念的情况是越来越严重了,非要造一个新词,显得自己先进。。。但是Agent服务企业本身这个话题还是值得了解和讨论的。

10 月 1 日,Salesforce 发布了《Multiplayer AI: The Shift from Smarter Individuals to a Smarter Company》,提出 AI 应该从单人模式(Single-player AI)走向多人协作模式(Multiplayer AI)1。几天后,Every 发布了 Every Agent,宣布从为每位员工配备个人 Agent,转向让整个公司共同使用一个 Agent2。Atlassian 也在 10 月 6 日发表《The End of Single-Player AI》,并推出了支持人类与 Agent 协作的 Agentic Multiplayer Protocol(AMP)3。

这些公司使用了不同的名称,包括 Company Agent、Shared Agent、Multiplayer AI,但都在探索一个共同的问题:当越来越多的员工开始使用 AI,企业应该如何将分散在个人手中的 AI 能力,转化为整个组织都能使用、积累和改进的生产力?

这一变化值得关注,因为它可能意味着企业 Agent 的产品形态、交互方式以及底层架构,都将发生新的变化。

01. 什么是企业 Agent?

企业 Agent(Enterprise Agent)通常指应用于企业环境、能够连接业务知识与系统,并根据任务目标自主或半自主执行工作的 AI 智能体。与普通聊天助手相比,它不仅需要理解自然语言,还需要具备工具调用、多步骤任务执行、业务系统集成以及权限管理等能力。

例如,一家企业可以部署财务 Agent 帮助员工查询经营数据,部署客服 Agent 处理客户问题,或者部署研发 Agent 分析代码、排查故障。这些都属于企业 Agent 的应用场景,因此企业 Agent 本身并不是一个刚刚出现的概念。

最近受到关注的是企业 Agent 的一种新形态:共享 Agent(Shared Agent / Company Agent)。 它强调让多个员工在共同的业务上下文中使用 Agent,并在一定范围内共享知识、技能和工作成果,使 Agent 能够持续参与组织协作。

举个例子,假设一家软件公司正在分析某个重要客户的投诉。销售人员需要了解客户诉求,研发人员需要排查技术问题,产品经理需要判断是否修改产品方案。

如果每个人都有一个独立的 AI 助手,销售可能需要向自己的 Agent 解释客户背景,研发需要向另一个 Agent 重新描述技术问题,产品经理又需要整理前两个人的讨论结果。虽然每位员工都可以借助 AI 提高效率,但整个流程仍然存在大量的信息传递和重复解释。

如果企业拥有一个共享 Agent,它就可以在获得相应授权的情况下,围绕同一个客户和任务维护共享上下文。销售可以让它整理投诉记录,研发可以继续让它查询相关日志,产品经理则可以基于前面的调查结果分析解决方案。Agent 还可以记录已经确认的结论、待处理问题和后续行动,让不同员工能够基于同一份任务状态继续工作。

这就是共享 Agent 的核心理念:让 AI 从个人任务的执行工具,逐渐成为多人共同协作的工作资源。

当然,共享 Agent 不意味着所有员工必须使用同一个大模型实例,也不意味着企业内的全部记忆和数据都可以互相访问。它强调的是在组织需要且权限允许的范围内,共享业务上下文、执行能力与工作成果。

02. 为什么企业 Agent 最近开始受到关注?

2.1 个人 Agent 提升了个人效率,却难以沉淀组织能力

个人 Agent 的优势非常明显,它能够根据用户的需求和偏好提供高度个性化的服务。但从企业的角度来看,每个人独立使用 Agent,也会产生新的知识孤岛。

假设某位运营人员花费大量时间,调试出一个效果很好的数据分析 Agent。它可以自动查询数据、分析异常、生成报告,甚至根据不同情况选择适当的分析方法。但其他运营人员可能根本不知道这个 Agent 的存在,即使知道,也需要重新配置工具、学习使用方法,或者将相关工作流迁移到自己的环境。

Every 就遇到了这样的问题。

2026 年初,Every 开始在内部推广基于 OpenClaw 的个人 Agent,并在 3 月推出 Plus One,为员工提供自己的 AI 助手。但随着使用时间增加,团队发现个人 Agent 的维护成本较高,而且优秀的使用方法很难在员工之间传播。

在 10 月 11 日发布的《One Agent for the Whole Company》中,Every 回顾了这段经历:最初建立的许多个人机器人后来逐渐停止使用,员工很难维护自己的 Agent,也记不住其他人的 Agent 分别具备什么能力。团队最终决定转向共享 Agent,让员工直接观察彼此如何使用 AI,并复用经过验证的工作方法4。

这揭示了个人 Agent 在企业推广中的一个问题:员工学会使用 AI,并不意味着他的经验能够自动转化为组织资产。 当企业希望扩大 AI 的应用范围时,就需要考虑如何降低能力传播、维护和复用的成本。

2.2 企业真正复杂的工作需要多人协作

Salesforce 在《Multiplayer AI》中指出,当前大量 AI 应用仍然处于单人模式:一个人在私人聊天窗口中与 Agent 合作,解决某个问题,然后结束对话。即使这个过程产生了有价值的经验,其他同事也未必能够看到或利用这些成果1。

但企业工作天然具有协作属性。一项产品发布可能涉及产品、研发、市场和销售部门;一次客户交付可能需要售前、实施、技术支持共同参与。这些任务往往持续数天甚至数周,期间不断产生新的信息、决策和执行结果。

当每个员工都拥有独立的 Agent,企业可能会出现一个有些矛盾的现象:个人处理任务的速度变快了,但团队仍然需要花费大量时间协调信息、同步进度和确认结果。

Dust 在 2026 年 5 月的文章中提出了类似观点。随着 Agent 可以独立承担越来越多的工作,企业面临的瓶颈正在从内容生成逐渐转向工作协调,包括多个 Agent 如何共享上下文、怎样在任务之间交接、谁负责审核,以及如何保证不同工作流朝着一致的目标推进5。

因此,共享 Agent 的重要价值之一,就是帮助企业降低跨人员、跨部门和跨系统的协作成本。

2.3 Agent 的技术基础设施正在成熟

企业共享 Agent 的出现也离不开底层技术的发展。

过去,许多 Agent 依赖个人维护运行环境和工具配置。如果希望让一个 Agent 长期运行,还需要解决任务状态保存、工具连接、身份认证、上下文管理等问题。一旦多个员工同时使用同一个 Agent,系统还需要处理会话隔离、权限冲突和并发执行等更加复杂的情况。

随着 Agent Runtime、持久化记忆、工具调用和托管基础设施的发展,开发者开始能够把更多精力放在业务流程和产品交互上。

Every 的技术文章《Why We Handed Our Agent's Infrastructure to Anthropic》就是一个例子。团队原本需要自行维护 Agent 运行基础设施,后来转向 Anthropic 的 Claude Managed Agents,把更多精力集中在共享 Agent 的产品能力上,但同时也需要接受托管方案在模型选择等方面的限制6。

尽管这并不意味着企业 Agent 的基础设施问题已经全部解决,但技术平台化正在降低企业构建和维护共享 Agent 的门槛。

03. 企业 Agent 能为企业带来什么价值?

从目前的实践来看,企业共享 Agent 的价值主要体现在三个层面:减少重复工作、改善团队协作,以及持续积累组织能力。

3.1 减少重复解释背景和交接信息的成本

企业中存在大量重复性的上下文传递工作。例如,新成员加入项目后需要了解项目背景,跨部门协作时需要重新说明需求,客户出现问题后又需要从不同系统中寻找历史记录。

一个能够连接企业知识、理解项目状态并维护任务记忆的 Agent,可以帮助员工减少这些准备工作。员工能够直接基于已有信息开始分析和行动,而不需要每次从头整理背景。

需要注意,共享上下文依然受到权限和数据范围限制。Agent 应当读取当前任务需要且用户有权访问的信息,而不是不加区分地向所有人开放企业数据。

3.2 让优秀的工作方法可以被整个团队复用

Every Agent 提供了一个值得参考的设计:当员工通过 Agent 完成某项任务后,可以将有效的工作流程保存为 Skill,让其他成员重复使用。

Every 在发布文章中提到,评测负责人 Mike Taylor 创建了一个每周重新整理工作优先级的 Skill,工程师 Nityesh Agarwal 随后也开始使用这个方法4。

这里的 Skill 可以理解为一套可复用的任务执行说明,可能包含操作步骤、工具使用规则、输出要求以及特殊情况的处理方式。当这些方法经过测试和维护后,就有机会成为整个团队可以调用的标准能力。

过去,企业主要通过 SOP、知识库和培训材料传播工作经验。共享 Agent 则提供了新的可能性:员工不仅能查阅某种工作方法,还能直接委托 Agent 按照这套方法执行任务。

从长远来看,企业知识的价值可能逐渐从“能够被检索”,延伸到“能够被直接用于执行工作”。

3.3 让组织的 AI 能力持续积累

个人 Agent 的价值通常围绕某位员工展开,而共享 Agent 可以围绕某个业务流程长期运行。员工能够复用前人的成果,发现问题后也可以提交反馈,帮助团队不断改进 Agent 的能力。

Dust 在 2026 年 10 月发布的《Dust Index》中提供了一组有意思的数据。在其企业客户中,只有 1.8% 的自定义 Agent 被至少 50 名不同用户使用,但这些 Agent 贡献了 43.3% 的消息和交互量。另外,65% 的 Agent 消息流向了被多名员工使用的自定义 Agent7。

这些数据表明,在 Dust 平台的使用场景中,少数得到广泛复用的 Agent 承担了相当大比例的实际工作。不过,这些统计来自 Dust 自身的平台,不能直接代表整个企业 Agent 市场,也无法单独证明共享 Agent 一定比个人 Agent 更高效。

更值得关注的是 Dust 提出的判断:当一个 Agent 能够被创建者之外的同事稳定使用,它才开始具备成为企业共享资产的条件。

04. 企业 Agent 有哪些实际应用案例?

目前,企业共享 Agent 尚未形成统一的产品形态,不同公司正在探索不同的实现路线。下面三个案例分别代表了共享 AI 同事、共享业务记忆和多人协作平台三种方向。

4.1 Every:让整个公司共享一个 AI 同事

2026 年 10 月 6 日,Every 正式发布 Every Agent。这是一个运行在 Slack 中的共享 Agent,员工可以在 Slack 线程中向它提出任务,让它调用工具、完成工作,并将有效的流程保存为 Skill2。

它的一个显著特点是公开协作。当员工在公开频道中使用 Agent 时,其他同事不仅能够看到最终结果,还能观察任务是如何提出、执行和修正的。这种方式使员工可以通过真实案例了解 Agent 的能力,也降低了新工作方法在团队内部传播的难度。

Every 的探索说明,共享 Agent 的价值未必完全来自更复杂的模型能力。有时候,让 Agent 出现在员工日常工作的地方,使成功经验更容易被观察和复制,就可能改善产品的使用情况。

4.2 Actively:为多个员工提供共享的客户业务记忆

2026 年 9 月,Actively 介绍了内部开发的 AI FDE。这是一个部署在 Slack 中的 Agent,主要用于协助工程师和客户管理人员处理企业客户的问题8。

最初,团队尝试把排查问题的方法封装为 Skills,让工程师在各自的开发工具中调用。但这些 Skills 的实际采用率很低,因为员工已经形成了自己的工具使用习惯,不愿意额外学习新的操作方式。

随后,Actively 把这些能力整合进一个 Slack Agent,让员工可以直接在工作讨论中请求它调查问题。根据该公司披露的数据,接入 Slack 前后两周的使用线程数从 4 增长到 158。

AI FDE 还为不同客户维护独立的记忆空间。例如,一位工程师向 Agent 解释了某个客户的特殊配置,其他有权限的员工随后也可以利用这些背景知识,无须从头解释。

这个案例体现了共享 Agent 的两个设计重点:Agent 需要融入现有协作流程,同时在适当的边界内共享业务记忆。 不过,使用量快速增长只能说明产品采用情况发生了变化,实际节省的工作时间和任务质量仍需要进一步评估。

4.3 Dust:通过共享工作空间组织多人和多个 Agent

Dust 采用了另一种思路,它没有要求整个公司只能使用一个 Agent,而是提供一个支持多人协作的 Agent 平台,让员工围绕团队、项目和业务流程创建共享工作空间。

在这种模式下,不同员工可以使用不同的专业 Agent,但这些 Agent 能够在授权范围内访问共同的业务上下文、工具和工作成果。

Dust 在 2026 年 5 月的融资公告中分享了团队筹备产品发布的过程。市场、数据和运营团队在同一个工作环境中与多个 Agent 并行协作,Agent 从 Slack、Snowflake、HubSpot、Notion 等系统中整理信息,协助生成营销材料、查询指标和跟进任务进度。人类成员则负责审查内容、处理阻塞和做出最终决策5。

这展示了共享 Agent 的另一种可能:企业不一定需要一个无所不能的超级 Agent,也可以通过统一的工作空间和上下文管理机制,让多个专业 Agent 共同参与业务流程。

05. 企业共享 Agent 需要怎样的技术架构?

从产品界面来看,共享 Agent 可能只是 Slack、Teams 或企业门户中的一个聊天窗口。但要让它真正支持多人协作,背后还需要一套完整的技术架构。

首先是协作入口和任务管理。 企业 Agent 需要能够接收多个员工的请求,理解这些请求分别属于哪个用户、项目或业务任务,并在必要时维持长期执行状态。例如,某个 Agent 需要持续跟进客户问题三天,它就应当知道任务已经完成了哪些步骤、有哪些待确认事项,以及应该向谁汇报结果。

其次是企业知识与共享记忆。 Agent 不仅需要查询文档,还需要理解企业的业务规则、流程规范和历史决策。这里可以区分个人记忆、项目记忆和组织记忆:个人记忆服务于用户自己的工作习惯,项目记忆记录特定任务的历史,组织记忆则保存经过确认、允许共享的业务知识与工作方法。

2026 年 7 月,SAP Signavio 等机构的研究人员发表了《Organizational Memory for Agentic Business Process Execution》。论文指出,如果企业把业务规则分别写进不同 Agent 的 Prompt 或检索配置,就容易产生知识孤岛、规则重复和更新不一致的问题。研究者因此提出,应当建立一个经过治理、可供多个 Agent 使用的组织记忆层,以支持企业业务流程的执行9。

第三是工具调用与运行环境。 Agent 需要通过 API、MCP 等接口连接企业业务系统,并在受控的 Runtime 中执行任务。例如,客服 Agent 可能需要查询 CRM、创建工单、更新客户记录;研发 Agent 可能需要访问代码仓库、运行测试并提交修改。在复杂业务场景中,系统还可以让一个主 Agent 协调多个专业 Agent 完成工作。

第四是身份与权限管理。 对个人 Agent 而言,很多操作可以直接使用用户自己的授权;但对于共享 Agent,权限问题会更加复杂。一个 Agent 可能同时服务不同部门,每个部门能够访问的数据并不相同,因此系统需要明确 Agent 自身拥有哪些权限、用户能够委托哪些操作,以及执行结果可以向谁展示。

Atlassian 于 2026 年 10 月发布的 Agentic Multiplayer Protocol(AMP)就提出了类似的架构思路。AMP 强调三个方面:让 Agent 直接参与现有工作流程;为每个 Agent 建立明确的身份与责任归属;通过共享上下文、细粒度权限和审计记录支持安全协作3。

最后是技能管理与持续改进机制。 当多个员工共同使用 Agent,企业需要考虑谁可以创建和发布 Skill,如何测试其可靠性,以及业务规则变化后如何更新。对于已经被大量员工依赖的 Agent,还需要建立负责人制度、质量评测、版本控制和必要的回滚机制。

可以发现,企业共享 Agent 的技术重点已经超出了单个 Agent 的推理和工具调用能力。它还需要解决多人之间的上下文共享、权限隔离、任务交接以及长期治理问题。

06. 企业 Agent 真正落地,还面临哪些挑战?

虽然企业共享 Agent 已经出现了一些实践,但距离大规模成熟应用仍有不少问题需要解决。

6.1 如何平衡共享记忆与数据安全?

共享记忆可以减少重复工作,但也可能产生信息泄露。例如,销售部门可以使用 Agent 查询客户业务背景,并不意味着它应该同时获得财务部门的全部合同资料。

因此,企业需要建立严格的记忆访问边界,避免把全部用户的对话记录直接合并成一个公共记忆库。不同用户、项目和业务领域需要相应的访问控制,对于敏感信息还应当保留来源、授权和审计记录。

6.2 如何保证共享能力的可靠性?

某个 Skill 在一次任务中表现良好,并不能说明它适用于所有情况。如果企业直接把未经验证的工作方法推广给所有员工,错误可能随着使用范围扩大而被放大。

因此,企业需要将个人探索与正式发布区分开来。员工可以自由尝试新的 Agent 工作流,但要把它变成团队共享能力,还需要经过测试、审核和持续维护。

Dust 的研究提到,1Password 允许员工创建自己的 Agent,但对正式发布共享 Agent 设置了更严格的管理要求7。这种机制实际上是在个人创新与企业标准化之间建立一道质量控制环节。

6.3 当多人共同使用 Agent,谁来承担责任?

这是企业 Agent 与个人 Agent 相比更需要重视的问题。

假设销售经理要求 Agent 修改客户报价,但另一个团队成员提出了不同意见,Agent 应该如何处理?如果 Agent 已经开始执行任务,谁有权暂停?如果操作涉及发送外部邮件、删除数据或修改合同,又应该由谁确认?

这些问题很难仅靠 Prompt 解决,需要明确的角色权限、任务所有权、操作审批和人工接管机制。

未来企业可能需要像管理软件账号和员工权限一样,对 Agent 建立正式的身份和责任管理体系。Atlassian 推出的 Agent 身份与非人类账号管理能力,正是朝这个方向进行的探索3。

6.4 如何衡量企业 Agent 的真实价值?

企业 Agent 的价值也不能只用对话次数或 Token 消耗来衡量。

一个 Agent 可能非常活跃,但如果它产生大量错误,员工仍然需要反复检查和纠正,那么实际收益可能有限。相反,一个使用频率不高的 Agent,如果能够显著缩短某项关键业务流程的处理时间,也可能具有很高的价值。

因此,企业应当围绕实际业务结果建立评测体系。例如,任务完成时间是否缩短,人工交接次数是否下降,跨部门重复沟通是否减少,Agent 输出的质量是否稳定,以及企业为每项成功任务付出了多少成本。

对于共享 Agent,还可以增加一些组织协作指标,例如共享 Skill 的复用率、跨部门使用率、知识更新及时性,以及同一类问题的重复发生率。

这些指标能够帮助企业区分两种情况:员工是否只是更频繁地使用了 AI,以及组织是否真正通过 AI 改进了工作方式。

07. 企业 Agent 的未来会是什么样?

从目前的产品实践来看,企业 Agent 正在探索三种不同的发展方向。

第一种是个人 Copilot,每位员工拥有自己的 AI 助手,主要解决个人工作中的任务。第二种是共享 Agent,团队成员围绕共同的业务上下文使用 AI,并复用知识和技能。第三种是更复杂的 Agent 协作系统,通过多个专业 Agent 与人类员工共同推进跨部门业务流程。

这三种模式并不一定互相取代。未来企业可能同时拥有个人助手、团队共享 Agent,以及负责特定业务流程的专业 Agent。它们之间通过统一的身份、权限、知识和任务管理机制协同工作。

相比之下,当前更值得关注的变化,是企业开始把 Agent 当作一种需要长期管理的组织资源。

过去,企业部署 AI 往往关注模型能回答什么问题、可以节省多少人工时间。现在,企业还需要思考:员工创造的 AI 工作流能否被其他人复用?Agent 能否随着业务发展积累有价值的知识?组织能否持续改进这些能力,并在更换底层模型后继续使用已有成果?

这也是企业 Agent 与传统知识管理、工作流自动化和企业协作软件开始产生交集的地方。未来一部分企业知识可能以可执行的 Skill 形式存在,一部分业务流程可能由 Agent 持续推进,而员工主要负责设定目标、处理例外情况和做出关键决策。

当然,这仍然是一个发展中的方向。Every、Dust、Atlassian 等公司的实践表明,共享 Agent 已经具备一定的产品可行性,但其长期收益、规模化可靠性和安全治理能力,还需要更多真实业务案例来验证。

企业 Agent 最值得期待的变化,是让 AI 的价值不再局限于某个员工完成了一次任务,而是让整个组织能够持续复用已经获得的知识、经验和执行能力。

当这些能力可以被安全地共享、持续地改进,并真正融入企业业务流程时,AI 才有机会从个人生产力工具,进一步发展为组织级生产力基础设施。

参考资料

以下资料按正文引用顺序整理,均附原文链接。

  1. Salesforce(2026 年 10 月 1 日),《Multiplayer AI: The Shift from Smarter Individuals to a Smarter Company》。讨论为什么个人 AI 使用模式难以自然带来组织级收益,以及共享工作空间的价值。

    原文:https://www.salesforce.com/news/stories/multiplayer-ai/

  2. Dan Shipper,Every(2026 年 10 月 6 日),《Introducing the Every Agent》。介绍 Every Agent 的设计理念、Slack 协作方式和 Skill 共享机制。

    原文:https://every.to/on-every/introducing-the-every-agent

  3. Mike Cannon-Brookes,Atlassian(2026 年 10 月 6 日),《The End of Single-Player AI》。讨论人类与 Agent 的多人协作模式,并介绍 Agentic Multiplayer Protocol。

    原文:https://www.atlassian.com/blog/company-news/team26-europe-founder-update

  4. Every Staff(2026 年 10 月 11 日),《One Agent for the Whole Company》。回顾 Every 从个人 Agent 转向共享 Agent 的原因及实践。

    原文:https://every.to/context-window/one-agent-for-the-whole-company

  5. Gabriel Hubert,Dust(2026 年 5 月 18 日),《Dust raises $40M Series B to scale multiplayer AI for human-agent collaboration》。介绍 Multiplayer AI 理念以及 Dust 内部跨团队协作案例。

    原文:https://dust.tt/blog/series-b-multiplayer-ai

  6. Paridhi Agarwal,Every(2026 年 10 月 8 日),《Why We Handed Our Agent's Infrastructure to Anthropic》。分析 Every 从自建 Agent 基础设施转向 Claude Managed Agents 的收益与代价。

    原文:https://every.to/source-code/why-we-handed-our-agent-s-infrastructure-to-anthropic

  7. Pauline Pham,Dust(2026 年 10 月 7 日),《Your AI strategy should outlast your favorite model》。基于 Dust Index 数据,讨论共享 Agent 的使用情况、模型选择、技能管理及成本治理。

    原文:https://dust.tt/blog/dust-index-ai-strategy-beyond-models

  8. David Hacker,Actively(2026 年 9 月 28 日),《Lessons from building an AI Forward Deployed Engineer》。介绍 Actively 如何通过 Slack 共享 Agent 与客户级记忆改善内部协作。

    原文:https://www.actively.ai/blog/how-we-built-an-ai-fde-that-became-one-of-our-most-valuable-teammates

  9. Lukas Kirchdorfer 等(2026 年 7 月),《Organizational Memory for Agentic Business Process Execution》。讨论企业 Agent 在业务流程执行中面临的知识孤岛问题,并提出组织记忆架构。

    论文:https://arxiv.org/abs/2607.03228

说明:本文中的产品机制、案例和统计数据均依据上述公开资料整理。关于企业 Agent 未来架构、组织级价值及发展趋势的判断,属于在这些材料基础上的分析与推演。涉及厂商披露的使用数据时,不将其直接等同于已经得到独立验证的业务收益。

本课产出

理解企业 Agent 的产品形态、价值、架构与治理问题。

完成课程