团队共用一个应用账号，Agent 连接后谁能用、谁来负责？

公共邮箱连上 Agent 后，整理询价、核对客户、确认回复由谁完成？从一封客户邮件，理解企业身份、业务工具和共享连接怎样共同支撑团队协作。

客户把询价邮件和产品附件发到销售公共邮箱。销售助理先让 Agent 提取产品、数量和交期要求，销售再核对 CRM 里的客户往来，负责人最后确认价格口径和回复内容。对客户来说，邮件始终来自同一个公司地址；对团队来说，这封邮件已经经过了几个人、几个系统和几次判断。

公共邮箱本来就是为了连续协作。有人休假或调岗，客户往来仍留在公司，接手的人可以继续处理。 Agent 接入后，整理附件、查找历史记录、准备回复这些工作还能更快。但问题也随之出现：如果 Agent 连接的是同一个邮箱账号，是否意味着团队里每个人都能通过它做同样的事？一封回复发出去以后，团队又怎样知道是谁发起、谁确认、用了什么依据？

都能处理这封邮件，不等于都能替公司回复

同一封询价里的动作，看起来都围绕邮件，责任却不同。销售助理可以把附件中的规格和数量整理成结构化信息，发现缺少交期时提醒销售补问。负责这个客户的销售可以查询 CRM ，确认过往报价和当前跟进状态。到了正式回复，价格、交期和承诺条件通常还需要负责人确认。

因此， Agent 能连接公共邮箱，只说明它找到了做事的地方。这个邮箱账号在后台也许具备读取、整理和发送的能力，但账号的最大权限不该直接变成每位员工调用 Agent 时的权限。能整理需求，不等于能遍历邮箱里的全部客户往来；能准备回复，也不等于可以绕过确认直接发送。

销售在群里说“帮我把这封询价整理一下”，通常不会把它理解成“允许你替我答应客户的所有条件”。让 Agent 接手时，这个日常分工需要变成明确的动作范围。把“读取指定询价”“补齐客户信息”“生成回复草稿”“发送已确认回复”分开，可以据此配置员工可用的工具，并限制 Agent 在这次任务中能够调用的动作。至于能处理哪些客户、哪封邮件，仍要结合业务系统的数据权限和流程规则确定，不能只靠一个授权范围名称解决。

账号留在连接里，具体动作交给员工和 Agent

围绕这封询价，可以用数犀集成平台的身份管理、 MCP 授权与连接流能力，把调用入口与后台执行账号分开组织。员工先用企业身份进入允许使用的应用； Agent 要访问企业开放的 MCP 服务时，再通过 MCP 授权进入相应服务。这里的授权回答的是“这个调用者能否访问哪些服务和工具”，并不会天然替代报价审批、客户归属等业务判断。

接下来， MCP 网关和连接流把业务系统里的能力组织成 Agent 可理解、可调用的工具。以这封询价为例，“准备回复”可以串起指定邮件读取、附件信息整理和 CRM 查询，输出一份待核对的草稿；“发送回复”则接收已确认的内容，调用邮箱动作完成发送。两个工具有不同的输入、动作和使用条件， Agent 无需面对一个可以任意操作邮箱的万能入口。

真正访问邮箱或 CRM 时，执行节点再选用对应的业务账号。这个账号可以由企业集中维护，凭证被相关连接流引用；同一条后台连接因而能服务多个工作环节，而不必把账号密码交给每位员工或写进每个 Agent 的任务说明。员工身份和 Agent 位于调用侧，公共邮箱账号位于执行侧，两者之间由明确的工具与流程连接起来。

在数犀集成平台中，业务账号的凭证可供连接流中的执行动作使用。查询客户信息可以选择 CRM 的授权账号，发送回复则选用销售公共邮箱的账号。维护人应盘点哪些流程使用这份凭证，再评估修改或停用的影响。目标邮箱是否支持读取指定邮件、保存草稿和发送回复，仍需按其 API 与授权范围核对。

客户追问时，要找的是这次任务

回复发出后，客户可能继续追问：“邮件里确认的交期，是按哪份库存信息判断的？”这时只看到公共邮箱账号没有太大帮助。团队真正需要找到的是那次任务：谁发起了询价处理， Agent 调用了哪个工具，草稿引用了哪些业务信息，谁确认了对外内容，执行节点最终返回了什么。

数犀集成平台的流程运行日志提供了排查基础。技术人员可以查看连接流的执行状态、节点请求与返回，以及错误发生的位置。配置变更还需结合相应管理记录核对；这些记录分别帮助排查流程运行和后台操作，却不能自动拼成完整的业务责任链。修改凭证的人，不一定是让 Agent 处理这封邮件的人；节点返回成功，也不一定证明客户已经收到邮件。

因此，在落地这类共享连接时，需要让业务任务、调用身份、 Agent 、工具、确认记录和执行结果使用可靠标识关联起来。比如围绕同一个询价任务号，从草稿生成一直带到发送节点和结果回读。哪些字段由身份系统、任务系统和业务系统提供，也要事先确定，不能让 Agent 自己生成一个名字就当作审计依据。数犀已有的身份、管理记录和运行日志为这条关联提供承载位置，具体字段是否贯通，仍属于实施设计和验证工作。

同事换了，客户往来不该重新连接

负责这位客户的销售调岗后，公共邮箱、历史邮件和既有连接仍属于公司。接手人需要继续查看待办、核对客户信息，必要时完成尚未发送的回复。这里不应该为了清理原员工的权限，就删除整条公共邮箱凭证，让其他连接流一起中断。

更合适的处理，是分别看四件事：原员工还能否进入相关应用，原有 Agent 授权是否需要调整，未完成任务由谁接手，公共连接由谁继续维护。它们的生命周期并不相同。数犀将用户与应用访问、鉴权凭证、连接流分别管理。一份凭证被多个流程引用时，修改会影响消费方，删除还可能使相关流程运行异常。这正说明，人员离场与公司连接停用需要分开处理。

连接维护责任也要随岗位变化交接。新负责人需要知道这条连接服务哪些流程、最近由谁修改、异常时从哪里查起。交接是否完成，还要在实际环境中检查原使用者的访问和存量授权，并确认新同事能继续处理任务；仅仅修改一处负责人姓名，并不足以结束交接。

从共用一个账号，到建立一套企业 Agent 协作体系

回到开头那封询价：销售助理需要整理附件，销售需要核对客户，负责人需要确认回复， IT 同事则要保证邮箱和 CRM 的连接持续可用。大家面对的是同一项业务，却分别站在身份、权限、执行和运维的不同位置。只把邮箱接给 Agent ，无法把这些分工一起安排好。

数犀集成平台在这里的完整价值，是把企业身份管理与应用集成放进同一套方案，让“谁可以使用”与“具体怎样执行”能够接在一起。 企业可以围绕一项业务配置人员入口、可调用工具、后台账号和执行流程，并为后续维护保留管理与运行记录。

对业务团队，常用的应用能力可以成为可复用的 Agent 工具。 员工沿用企业身份进入获准应用；通过 MCP 授权、网关和连接流，可以把客户查询、询价整理、回复发送组织成具体工具。后续接入新的 Agent 时，就有机会复用这些已经梳理过的业务动作，而不用重新从“把哪个账号交给它”开始讨论。

对 IT 团队，连接与账号可以集中维护，业务分工落在流程里。 鉴权凭证集中配置和测试，动作节点选用对应账号，连接流组织跨系统的处理步骤。准备回复与正式发送分开，需要确认的动作按业务要求配置确认环节。公司邮箱持续服务多个流程，人员变化时则分别处理访问、任务与维护责任，避免把某个人的离场变成整条业务连接的停摆。

对业务负责人和运维同事，执行过程有了共同排查的基础。 连接流日志用于查看节点请求、返回和错误，管理记录用于核对配置改动；再把这些记录与业务任务、确认依据关联，团队才能从“邮件发没发”继续追到“当时按什么做、下一步由谁接手”。完整关联需要在接入方案中落实，但不必再把身份、连接、执行和排查当作四件互不相干的事。

先把一封询价的协作安排清楚，企业才能把同样的方法用到其他应用：公司维护业务连接，员工和 Agent 按职责使用工具，执行结果回到业务任务。

让 Agent 接入一个账号，只是建立连接；让团队持续、按分工使用企业应用，才是可复用的协作能力。数犀集成平台把身份与集成衔接起来，帮助企业把这套分工从公共邮箱扩展到更多业务。