如果有一天，你打开公司的通讯录，发现里面多了一位项目协调员。
它有自己的邮箱、日历和资料空间。同事可以把它拉进项目群，在文档里提到它，也可以把一项持续的工作交给它。第二天换一个人接着沟通，它仍然知道这个项目在推进什么。
这位协调员是一名 AI Agent。
这样的产品形态正在被大厂认真推动。2026 年 10 月 8 日，Google 在 Gemini at Work 的公告中介绍了 coworker agent：它可以拥有独立的 Workspace 账号、邮箱、日历、Drive，以及公司目录中的位置；同事通过聊天和文档评论与它协作，修改记录归到它自己的身份下。
这条消息很容易被理解成“AI 办公又多了一个新功能”。但如果顺着它往后推，值得关注的变化要大得多。
当 AI 拥有一个可以被同事持续找到的身份，企业就开始面对怎样给它安排职责、交接工作和确认责任的问题。
这里的“岗位”是一种组织协作的比喻：一段稳定的职责、一个明确的委托关系，以及一套别人能够据此继续工作的约定。机器不因此成为最终承担业务后果的人。恰恰因为后果仍然属于组织，企业才需要认真设计这种新的工作关系。
独立邮箱让工作有了持续的接收位置
我们已经习惯了一种 AI 使用方式：员工打开聊天窗口，把资料贴进去，获得结果，再将结果复制回办公软件或业务系统。
这一过程中，工作关系主要存在于员工与助手之间。同事知道要找这名员工，却未必知道怎样找到他正在使用的助手。员工休假、转岗或者更换工具以后，其他人常常需要重新理解事情的来龙去脉。
独立的协作身份提供了另一种可能。
项目通知可以到达同一个接收位置，成员可以围绕同一段职责交办，工作记录可以留在共同使用的空间里。一个人负责提出目标，另一个人补充资料，第三个人回来验收，他们不必都依赖最初那个人的私人聊天窗口。
邮箱本身没有创造推理能力。它改变的是工作如何被找到、被接续，以及归到哪个执行角色名下。
传统软件中，企业早就使用共享邮箱、服务账号和工单队列承接这类工作。Agent 带来的新问题在于：接收信息以后，它还可能理解目标、选择步骤、调用系统并持续推进。组织需要为这种行动能力安排更明确的工作关系。
因此，一个团队 Agent 的价值，不能只看它能否写出一份更漂亮的文档。还要看不同同事能否围绕它协作，任务是否有稳定的去向，以及事情进行到一半时，别人能否接得上。
企业需要先定义它承担哪一段工作
设想一家提供设备服务的企业，为项目组配置了一个交付协调 Agent。
它接收指定项目的客户资料，整理尚未补齐的文件，汇总内部进度，提醒对应负责人，并更新允许范围内的待办。到了约定时间，它还可以准备一份交付说明，列出已完成事项和仍需确认的条件。
这是一个足够具体、也有持续价值的角色。
但是，“项目协调员”这个名字并没有回答所有问题。它是否可以直接对客户承诺日期？是否可以宣布验收通过？能否关闭项目，或者触发后续付款？
这些动作会带来不同的组织后果。发现材料齐全、准备验收文件和正式确认验收，是可以分别委托的工作。它们不应当因为出现在同一段对话里，就自动合并成一份无限扩大的许可。
企业为这个角色确定职责时，应当说明它负责推进什么、可以使用哪些资料、哪些动作已经允许，以及遇到什么条件需要负责人决定。对于已经委托、条件仍然成立的工作，它可以持续执行；当变化超出原有范围，或者使必要条件不再成立时，再交给对应的负责人决定。
这种安排也有助于减少无效确认。把职责写清楚以后，系统无需在每一步都问“是否继续”；它可以只在真正产生新承诺、扩大工作范围或者触及关键业务状态时请求决定。
清楚的职责，会同时改善自动推进的效率和人对工作的掌控。
这需要业务负责人参与。技术团队可以维护运行环境和连接方式，却不能独自决定一项交付何时获得组织认可。微软的 Entra Agent ID 管理文档，也将技术所有者与业务赞助人分开：前者负责配置和凭证，后者关心 Agent 的目的、生命周期和访问复核。
这类分工透露出一个方向：Agent 管理正在进入企业管理，而不只停留在工具安装和模型选择。
群里每个人的话都需要保留各自的分量
团队使用 AI 时，一个容易被低估的问题是委托来源。
继续看这个项目。客户在邮件中希望提前交付，工程师在群里说主要功能已经完成，销售表示可以尽快推进，项目负责人则要求等现场检查结果回来再确认。
这些信息都与任务有关，但它们承担的作用不同。
客户提出需求，工程师提供进度事实，销售表达业务诉求，负责人给出当前决定。Agent 可以理解这些内容、整理分歧并寻找下一步，却需要继续保留每项决定来自谁、适用于什么事情。
如果只是把整段群聊作为上下文，让模型根据最强烈、最靠近结尾的表达向前执行，组织原有的决定关系就可能被语言的表面顺序取代。
这一点也影响权限。一个项目群里可能同时有销售、财务、工程师和外部供应商。Agent 加入群聊以后，不应当自然获得所有成员权限的并集。能看到相关讨论，与能够使用其中某个人的业务权力，需要分别处理。
独立身份能够帮助我们识别执行者，但一次行动还应当说明它依据谁的委托、面向哪个项目、在什么范围内发生。有些动作由组织直接授权给这个角色，有些则代表某个用户执行具体任务。代表用户行动时，系统需要同时保留 Agent 的执行身份和用户的委托身份，并由业务系统验证这项操作的实际权限。
Google 在介绍 coworker agent 时，同样强调共享范围和成员关系，并将身份、权限与审计作为企业能力的一部分。这说明独立账号提供的是组织管理的起点，后续授权仍需落实到实际系统。
对用户而言，这些关系应该尽量由系统可靠传递。他只需要自然地表达目标，无须每次都重新解释自己的职位、部门和所有权限。对组织而言，自然的交互又必须留下明确的决定来源。
协作越顺畅，背后越需要把这些关系安排清楚。
团队经验怎样留下来，决定岗位能否被交接
一个 AI 角色承担持续工作以后，任务记录和同事的反馈会逐渐留下可供团队总结的经验。
哪些客户需要提前提醒，哪些项目容易漏掉附件，哪类变更通常需要工程师复核，交付说明应当怎样组织。这些经验会影响下一次工作能否更快、更准确地推进。
如果它们只存在于最初配置者的聊天记录中，这个角色的持续性就很脆弱。换一个同事、开一个新会话或者更换模型，团队可能又要从头解释。
因此，企业有必要把可复用的工作经验，逐步整理成能够交接的资料和约定。但整理经验也需要区分不同内容。
某位客户曾经喜欢简短的邮件，这是可以参考的偏好；某份文件是当前交付模板，这是带版本的组织规则；某个人曾经允许提前提交，则可能只是当时、针对那个项目的一次决定。
如果把它们都保存成“以后照做”的记忆，经验就会混入已经失效的许可。
好的经验积累应当带着来源、适用范围和更新条件。组织需要知道一条结论来自正式制度、负责人决定，还是一次任务中的临时判断；项目结束、人员转岗或资料撤回以后，也需要调整它的后续使用范围。
这意味着，记忆能力的竞争会逐渐延伸到经验治理。存得更多只是其中一部分，企业更关心哪些经验值得留下、谁能够使用，以及发现错误后能否纠正。
同样，团队经验与个人信息应当有合适的共享范围。某位员工为了获得个人帮助，告诉助手的私人情况，并不会因为这个助手后来进入项目群，就自动成为团队资料。
当经验可以被核对、修订和交接，AI 的工作才有机会从个人习惯发展为组织能力。
一个持续的岗位也需要变更和结束
人们谈论“数字同事”时，常常把重点放在启动：怎样创建一个 Agent，怎样给它工具，怎样让它记住工作。
但组织中的岗位会经历变化。
项目负责人会调岗，客户合同会结束，工作范围会调整，原有资料会被新的版本替代。某个 Agent 也可能因为价值不足、职责重复或者项目结束而不再需要继续运行。
企业因此需要考虑它的整个使用过程：谁决定设立这个角色，谁维护它的业务目的，职责变化后谁复核访问范围，停止使用时怎样处理尚未完成的工作。
例如，交付协调 Agent 已经提交了一项预约，但预约结果尚未返回。项目结束时，停止接受新任务是一件事，确认这项已发出的预约最终怎样了，则是另一件仍需有人接手的事。
如果只是关闭界面、删除入口，已经发生的工作不会因此消失。组织需要保留能够追踪原操作的记录，并将尚未结束的事项交给负责人。
负责人变更时，需要明确由谁承接职责，并复核这个 Agent 还需要哪些资料和权限。已经完成的工作，则继续保留当时的执行身份、委托来源和决定依据。
岗位的持续性，来自工作可以延续；岗位的可控性，来自工作也能被调整和有序结束。两者共同决定企业是否愿意把更多事情长期交给 AI。
节省下来的时间应该落到整个团队
从个人助手走向团队角色以后，企业评估价值的方式也会发生变化。
一个员工使用 AI 半小时写出过去需要两小时的报告，收益相对容易理解。团队 Agent 则可能同时减少资料催收、进度同步、会议准备和跨部门交接的时间，价值分散在多个人的日常工作中。
也可能发生另一种情况：它生成了很多汇总，却让负责人每天花更多时间检查；通知增加了，同事开始忽略提醒；自动更新的记录很丰富，但真正的项目风险仍然需要人工重新排查。
因此，企业需要观察整个团队为了完成同一项工作付出了多少注意力。资料是否少追问了一次，遗漏是否更早被发现，异常是否更快到达正确的人，下一位接手者是否能够直接继续。
这种评估也会影响组织扩张的方式。自动执行成本下降以后，一个负责人可能同时管理更多项目；如果监督和交接方式没有跟上，节省下来的时间又可能被不断扩大的检查负担消耗。
AI 能力增加，需要与人的注意力容量一起考虑。
在交付协调这个例子里，一个实用的起点是记录资料补齐所需时间、人工催收次数、重新解释背景的次数，以及负责人接手时仍需确认的事项。企业可以通过这些变化判断是否值得扩大职责，而不必一开始就用“替代了几个员工”作为目标。
这样，岗位设计会保持具体：它在哪一段协作中产生了持续价值，就逐步扩大哪一段委托。
企业长期积累的价值会超出某个模型
当 AI 开始承担组织角色，企业还会遇到一个长期选择：这些角色的工作能力应当依附于什么？
模型会更新，办公入口会变化，某个产品在一类任务上的优势也可能随着时间改变。企业使用新模型时，仍然希望保留已经明确的职责、业务规则、可信资料和工作记录。
这会推动企业把一些东西作为自身能够管理的资产：可调用的业务能力、稳定的语义、任务的有效范围、对应的决定来源，以及可以被下一位执行者理解的结果。
统一办公平台能够降低协作成本，集中管理也有明显价值。与此同时，许多企业的核心事实仍然分布在已有的 ERP、CRM、项目系统和行业软件中。Agent 如何进入这些系统，并且继续遵守它们的实时规则，仍是一项实际建设工作。
开放的接口、明确的能力声明和可还原的执行记录，可以帮助企业在工具变化时保留这些积累。具体接入仍需要处理身份、语义和业务规则，不能仅靠更换一个模型名称完成。
这里值得警惕的依赖并不只来自某个厂商。企业如果把所有工作经验和决定都藏进一个人的私人对话，同样会形成难以交接的依赖。组织建设需要同时减少对单一工具和单一人员的脆弱依赖。
从这个角度看，AI 办公的发展可能把企业的竞争进一步推向工作组织能力：谁能把经验整理成可复用的约定，谁能让授权随着任务变化，谁能让后续的人更容易接手。
这些能力会影响企业究竟能够放心委托多少工作。
先安排一个清楚的角色，再逐步扩大委托
并非每项工作都适合建立一个长期 Agent 角色。
偶尔使用的翻译、一次性的资料整理，个人助手可能已经足够。规则明确、变化很少的定时计算，确定性流程通常更容易维护。持续协调信息、处理多种输入、根据情境选择下一步的工作，才更可能从团队 Agent 中获得额外收益。
企业可以先选一段有明确负责人、能够核对结果的持续工作。让它使用指定资料和已有系统，从整理、提醒、准备草稿或者低风险更新开始，观察团队是否减少了重复沟通与接手成本，再决定进一步允许哪些动作。
这样的起点，有利于把“岗位”落实到实际职责，而不只是在通讯录里增加一个名称。
当这一角色开始进入真实业务系统，组织还需要让每次行动与委托关系、能力范围和实际授权相连。我们将这类 Agent 进入业务并产生组织后果的问题称为 A2B。ACC 尝试用实现中立的能力契约，表达业务能力面向 Agent 时的治理要求；BailingHub 则提供将这些要求落实到接入、执行控制和追踪中的开源工程实践。
这些工作服务于一条连续的责任关系：人和组织提出目标、决定委托，Agent 宿主组织步骤，运行链路执行对应约束，业务系统根据实时事实作最终授权，并留下可以接手的结果记录。
未来，一个 AI 的邮箱地址可能会变得很普通。更能决定企业从中获得多少价值的，是它背后是否有清楚的职责、有效的工作关系，以及愿意接过结果的人。
