正文
我认为，企业协作下一步会从“人给 Agent 派活，再由人转交结果”，逐渐走向“Agent 在授权目标内定义子任务、寻找协作者并对齐交付标准”。 人可以减少日常对接，把精力放到责任承担、权限划分和异常介入。实现这个愿景，关键在于正确的上下文与可执行的权限边界。市场机会更可能集中在两类公司，Anthropic 这样的强模型提供商，以及飞书、企业微信这样的企业协作平台。前者能联合优化模型与任务执行，后者掌握现有工作入口、组织关系和企业服务；完整任务的可靠交付仍是两者都要证明的条件。
实习中，交接仍然由人完成
在我实习接触的开发流程里，产品经理可以让 Agent 整理需求，开发团队则用 Coding Agent 实现和做初步测试，PR review 也会用到 Agent。各岗位的执行方式已经变化，但是任务之间的衔接和对齐仍主要靠人。
产品经理确认 Agent 产物后交给开发，开发再组织自己的 Agent 执行，遇到信息缺口或理解偏差，还要由人联系另一方。员工既是业务负责人，也在反复派活、补上下文和搬运结果。单个步骤做得更快以后，这部分协调工作会更显眼以及更占据精力。
因此我对于后续企业间协作的期待是：下一阶段的 Agent 应能在明确目标和权限内，自己判断需要哪些子任务，找到具备相应能力的协作者，并把什么算做好了说清楚。它也要能接住对方的产物，发现缺少的信息，决定继续、重试还是交还给人。
Agent 自主对接，需要把工作标准一起交过去
首先我们可以举例一个场景*“降低注册流程流失率”*。产品经理在提出目标和业务约束后，Product Agent 整理需求，寻找能修改对应模块的开发 Dev Agent，再确认交付物和测试标准。开发遇到需求歧义时，返回具体问题给Product Agent，朝着goal进行迭代的任务改进；测试 Agent 则按同一套要求验证结果。
这条链里，Agent 可以决定怎样完成已授权的工作，不能自行修改业务目标或扩大权限。发现需求相互冲突、需要改变风控规则，或准备做高风险生产变更时，它应把决定交还给负责人。
A2A 协议已经定义能力描述、任务状态与产物等基本对象，为不同 Agent 交换信息提供共同格式。[1] 选择谁来协作、任务要怎样拆、证据是否足够，仍需要模型和运行系统判断。只把消息传出去，离一次成功交付还有距离。
人的工作因此也会随之变化。各个业务的负责人继续承担目标与结果责任，确定哪些动作能自动执行，并在异常发生时介入。Agent 可以承担执行和日常调度，组织不能把责任归属一起交给模型。
Claude Tag 和豆包工作伙伴已经接近这个方向
Claude Tag 把 Agent 放进 Slack 共享频道。团队成员可以围绕同一个 Claude 派任务、补材料和接续工作；开启相应设置后，它还能够主动跟进讨论和异步任务。[2] 这已经超出个人聊天框，但多人共用一个 Agent，与多个 Agent 自主发现彼此、协商分工仍有区别。
豆包工作伙伴的官方说明则包含小队协同，多个伙伴可以拆解任务、并行工作并交接产物，人能够查看过程和中途纠偏。功能手册还描述了第三方或企业自建 Agent 接入，以及任务共享资料与单个 Agent 内部状态的区分。[3][4]
我期待的是这些产品未来更先进的版本。它们能够根据工作需要选择协作者，在职责边界内确定子任务，并把交付标准带到下一方。目前已有的这些共享记忆、任务接力已经有一定的基础，但是距离更自主、更稳定的运行还有一段距离。
正确的上下文与权限决定协作能走多远
上下文要让接收方知道当前该做什么。 目标、有效决定和验收要求，需要与交付物一起传递；过期结论和某个 Agent 尚未确认的推测，不应混成组织事实。历史记录可以长期保存，每次任务只应读取有权限、与当前工作相关的部分。
企业拥有大量文档，只能说明资料存在。Agent 还要判断版本是否有效、不同部门的要求是否冲突，以及当前缺口应向谁询问。错误上下文会让多个执行者把同一个误解继续传播下去。
权限要在读取和执行时真正生效。 Agent 声称自己只做某些事情，不能替代工具与系统的授权检查。任务移交后，接收方能看什么、能改什么，需要重新确认；原负责人拥有某项权限，不意味着所有协作者都可以继承它。
Claude Tag 的频道 Agent 使用自己的服务身份，频道成员可以请求它使用已授予的权限，未必与每位成员个人权限相同。[5] 企业因此要管理频道成员和 Agent 的权限组合，不能默认共享频道天然安全。一个场景里方便的共享机制，在另一场景里可能扩大信息披露范围。
只有这些边界明确，人才能减少逐步盯着执行的负担。异常时还应看得见已经做过什么、哪里出了问题，必要时停止或恢复任务。自主协作与可介入的过程需要一起建立。
我更看好两类竞争者
一类是 Anthropic 这样的强模型提供商。 它们拥有规划、推理和工具使用能力，可以把模型与上下文管理、任务执行做成同一产品。Claude Tag 说明模型厂商可以借助既有协作入口直接参与企业工作，协作平台掌握入口，也不保证能拿走全部价值。[2]
这类公司的机会，在于更前沿智能的模型能更加高效的完成任务、以及用真实任务的完成结果与纠正反馈改进模型及产品，让更复杂的工作得到可靠交付。需要区分产品调度优化、企业内部经验复用和模型参数训练，企业私有数据不能默认转成供应商训练资源。模型优势只有持续体现为更少返工、更低人工复核成本，才能支持长期付费。
另一类是飞书、企业微信这样的企业协作平台。 员工已经在其中沟通，文档、组织关系和业务流程也已接入。Agent 如果能在原有授权下获得正确材料，并把成果交回员工继续使用的系统，就能减少迁移与重新配置的成本。用户黏性和完善的企业服务，使这些平台拥有部署与分发的基础。
模型接入是这条路径的必要条件。飞书可以结合字节自研模型和伙伴执行体系优化产品；企业微信的官方文档也已经列出 DeepSeek、混元及企业自有模型接入。[3][6] 企微的现有接入能力，并不证明它已经具备同等程度的自主多 Agent 协作，平台仍要把模型能力转成完整流程的交付表现。
平台也有条件形成数据反馈。已授权的任务产物、人工纠正和验收结果，可以帮助改进上下文检索与协作流程。飞书官方明确表示团队与企业私有数据不用于模型训练，因此不能把“接近真实业务”直接写成“可以拿客户资料训练底层模型”。[3]
这两类公司分别从模型能力与企业入口出发，竞争会落到同一件事上，谁能让 Agent 接住完整任务，同时让负责人保留有效控制。
看人是否真的少做了对接
判断这类产品的价值，要注意看整项任务的交付周期，以及人工补充上下文、转交产物和纠错的次数。员工若依旧要逐项重做检查，自主协作的收益就有限，模型调用增加也不能证明节省了时间。
企业有理由调整分工，要等 Agent 已经减少日常对接，同时能在异常时把问题交给合适的负责人。人的责任还在，精力却可以逐步从搬运结果转向目标取舍与权限管理。这是我期待的组织变化。
关键来源
- A2A 协议规范，能力描述、任务状态与产物。
- Anthropic 的 Claude Tag 发布说明，共享频道、主动跟进和异步任务。
- 飞书的豆包工作官方说明，产品体系、小队协同及企业私有数据政策。
- 豆包工作伙伴功能手册，Agent 接入、团队任务与上下文分层。
- Claude Tag 的身份与访问模型，频道 Agent 身份与个人权限的区别。
- 企业微信智能机器人官方帮助，模型接入、知识、插件与工作流。
本文修订与资料核验截至 2026-10-09。产品能力按官方说明理解，自主协作的长期愿景与已经公开的功能分别表述。