办公 Agent 试用起来了，团队怎样真正协同起来？

从企业身份与业务接入，到 Context 持续供给和协作资产复用，看人与 Agent 怎样共同构建企业工作流程。

设想这样一个时刻：销售让 Agent 整理客户资料，同事补充了判断口径。下一次换另一位同事跟进时，他已经可以调用团队验证过的技能，沿着约定流程准备材料、确认行动、更新记录，不必从头解释一遍业务。

一次协作留下了两份成果：眼前的任务交付，以及下一次可以继续使用的工作方法。

这正是企业试用千问办公、WorkBuddy、豆包工作等办公 Agent 时，值得进一步验证的价值。从员工进入工作台，到 Agent 取得资料、调用业务工具，再到人与 Agent 共同积累 Context、Skill 和 Workflow，集成平台可以沿着整条旅程参与，而不只是最后把结果搬进一个系统。

第一步：沿用企业账号，进入 Agent 工作台

销售第一次打开 Agent 工作台，理想的体验是继续使用平时的企业账号和登录方式，直接进入获准使用的应用。多一个 Agent 工作台，不应让员工多记一套用户名和密码，也不应让管理员多维护一份孤立的人员名单。

对于支持企业统一认证、且已完成接入的 Agent 平台，可以将登录接回企业现有身份体系。员工在企业认证入口使用原有账密，或企业已经采用的其他认证方式；已有有效登录会话时，还可以按企业策略单点进入工作台。密码策略、多因素验证和访问要求继续由统一体系管理，员工也不必为每个新助手重新建立一套登录习惯。

这里的关键，是沿用同一套企业身份与认证体验。目标应用可能仍需要一个与企业身份对应的用户记录，用于归属数据、分配席位和配置权限。这类记录可以在目标平台支持的情况下，通过身份同步或账号映射集中维护，而不是让员工自行注册并管理另一套独立账密。统一认证也不需要把企业密码复制到每个 Agent 平台。

数犀的身份集成可以将账号同步、统一认证和应用访问管理衔接起来：员工加入团队时准备相应访问，调岗时调整关联，离职或退出项目时按规则收回权限。具体同步方式、登录协议与停用行为，需要结合目标平台和部署配置核对。

员工如何登录，与 Agent 使用什么身份调用业务系统，仍是两个环节。沿用企业账号进入工作台后，Agent 的执行身份和本次任务授权还需要单独明确。

登录入口，也是业务旅程的一部分

沿用企业账号之后，登录页面也应延续熟悉的体验。员工打开“销售协作助手”，看到企业的名称、标识和惯用登录方式，就能清楚知道自己正在进入哪个组织的应用。

数犀手册中的登录页面配置包含平台名称、Logo、背景、登录框布局以及页面样式等内容。对于经统一身份入口接入的 Agent 应用，可以围绕这一入口组织品牌化登录体验，再将员工带回目标应用。

这个入口解决的是“谁在进入应用”。进入后能查询哪些客户资料、调用哪些动作，还需要业务系统侧的授权继续约束。品牌化也应发生在企业能够管理的认证入口，不能据此认为任意第三方 Agent 平台的登录页面都可以修改。

人给出目标，Agent 和同事共同推进任务

回到客户跟进场景。销售已经登录工作台，提出目标：“根据上次会议纪要和当前客户记录，准备下一次沟通的建议。”

如果这些资料散落在文档、CRM 和其他系统里，集成平台的下一项工作，就是把经过授权的数据查询和业务动作组织成可调用的连接。具体通过 API、连接器还是适配的工具服务接入，应依据所用 Agent 和目标系统的能力确定。

Agent 可以据此整理事实、比较信息、起草建议；遇到材料冲突或缺少判断依据时，把问题交回给人。例如，客户曾提到“希望尽快试用”，同事补充：只有明确了试用负责人和数据范围，才进入安排阶段。

这段补充很重要。它既改变了当前建议，也暴露出一个可以被记录、检验和复用的业务判断。人与 Agent 的协作由此开始超出“生成一份文件”。

交给下一位同事时，保留结果、来源、待确认事项和负责人即可，不必复制整个聊天过程。接收者应在自己的权限范围内查看依据；需要额外资料时，通过正常授权补齐，不能随着任务交接一并传递个人凭证。

把确认后的决定，变成可核对的业务动作

同事确认了下一步安排，集成平台还需要把这个决定接回业务系统：找到正确的客户记录，按允许字段写入跟进时间和待办，再读取对应记录核对结果。

这里应保留清楚的过程状态：建议已经生成、业务决定已经确认、系统记录已经更新。若目标记录已经变化，就保留差异等待处理；请求超时则先确认系统实际状态，再决定是否重试，避免重复创建任务。

这样，员工能知道任务推进到哪里，Agent 也能依据明确的执行结果继续工作。尚未具备连接的部分，可以先由人完成并记录结果，再决定是否值得建设自动化。

身份接入让合适的人进入，数据连接提供任务所需的信息，执行编排让确认后的动作得到落实。 把这些环节连起来，集成平台才能持续支撑人与 Agent 的业务协作。

这是一条建设思路，不代表上述办公 Agent 已经与数犀或指定 CRM 完成整条链路的适配。

真正的转折：每做一次，都能留下新的协作资产

第一次任务结束时，可以请 Agent 回看刚才的配合：哪些事实影响了判断？哪些经验是同事补充的？哪些步骤可以稳定执行，哪些必须先询问？

人把经验、限制和反例讲清楚，Agent 协助整理，再由负责人验证。留下来的资产，不只有 Skill 和 Workflow，还包括后续任务需要的 Context。

Context 留下“这件事目前是什么情况”。 在客户跟进中，它可以包括客户正在推进的项目、上次沟通的结论、已经确认的试用负责人，以及尚未解决的问题。这些信息应带着来源、更新时间和访问范围，供后续任务检索使用。

Skill 留下“怎样做这类任务”。 客户跟进准备技能说明需要哪些材料、如何区分事实和建议、遇到试用需求应补问什么，以及成果应如何交付。它把几次对话中的经验，整理成下一次可调用的方法。

Workflow 留下“业务动作怎样接续”。 读取客户资料、提交待确认项、确认后更新指定字段、回读记录、通知负责人，构成可以维护和复用的执行步骤。需要判断的部分，则留给人或适当的 Agent 环节处理。

三者配合起来，下一位同事既能知道当前进展，也能使用团队验证过的方法与流程。不同平台的格式和共享方式仍需分别适配。

业务变化，怎样持续成为可用的 Context？

假设客户刚在会议中明确了试用负责人，CRM 更新了预计时间，试用工单又增加了一项前置条件。如果这些变化还要员工逐个复制到每个助手里，团队很快就会维护出几份不同的“最新情况”。

第一条链路，是业务系统持续向 Context 供给信息。集成平台可以按事件或计划读取已授权的变化，将 CRM 记录、会议纪要和试用工单关联到同一客户或项目，再把标准化的记录交给上下文服务处理。业务团队可以定义哪些变化触发更新、哪些字段参与关联、哪些信息需要人工确认。

这条链路的质量，取决于更新之后还能否核对：事实来自哪里，何时发生，是否已被新记录替代？源数据被删除或访问被撤销时，相关副本与派生内容也需要按规则处理。旧判断不应一直以“当前事实”的身份出现在后续回答中。

集成平台在这里负责连接、调度、格式转换和更新衔接；上下文服务负责进一步整理、检索与组织相关背景。两边共同维护好数据关系，才能让持续供给真正有用。

Context 准备好了，怎样进入下一次工作？

第二条链路，是Context 按任务需要向应用供给信息。销售准备客户沟通时，可以请求这个客户近期已确认的进展与待办；项目负责人准备周会时，可以获取跨系统的阻塞事项；新同事接手项目时，可以先了解关键决定及其依据。

这三种任务需要的内容并不相同。集成平台可以衔接业务应用、上下文服务与 Agent，把员工身份、任务对象和查询条件带入受控接口，由上下文服务返回相关内容及来源。供给时仍要核对当前访问权限，不能因为一份资料曾被采集，就默认任何应用或接手同事都能看到。

Context 帮助 Agent 理解任务，业务动作仍要走各自的授权与确认流程。了解某个客户的背景，并不自动取得修改客户记录的权限。

任务完成后，已确认的结果又可以补回 Context：客户安排更新了什么，同事最终选择了哪个方案，哪些问题仍然待定。Agent 的推测先作为待核验内容，新的方法先经样例验证，再进入共享 Skill 或 Workflow。

再回到开头的时刻：第二位同事开始跟进时，可以从更新过的客户背景、验证过的技能和可执行的流程出发。遇到新情况，他补充判断，Agent 协助整理，负责人确认后再纳入下一轮使用。

业务变化进入 Context，Context 支撑应用和 Agent，经过确认的工作结果再成为后续背景。 这两条供给链路持续运转，团队积累的就不只是文档数量，而是能够在下一次工作中用起来的业务经验。具体供给方式需要结合目标系统、上下文服务和权限机制建设，不能由一份共享摘要替代。

让企业真正 Ready for Agent

员工需要一个顺畅的入口，Agent 需要可调用的业务能力，企业则需要明确访问边界、执行规则和结果。数犀集成平台将身份集成与应用集成放在一起，可以围绕四个方面，为人与 Agent 的协作做好准备。

企业应用：让现有 API 成为可授权使用的 MCP 工具。 数犀集成平台提供 MCP 网关与 MCP Auth 两部分能力：通过网关将企业应用已有的 API 接入、转换为 Agent 可调用的 MCP 工具，通过 MCP Auth 衔接用户授权与工具访问。前者解决业务能力怎样开放给 Agent，后者处理谁可以在什么授权范围内使用。结合连接、字段转换和结果聚合，平台团队可以集中维护工具接口、输入输出与失败含义，业务团队围绕任务使用这些能力。具体工具与授权链路仍需结合目标系统完成适配和验证。

企业身份：统一管理人和 Agent，明确两者的委托关系。 员工沿用企业账号与认证方式，应用侧身份集中同步和维护；Agent 则有可识别的执行身份，关联管理责任人与本次委托员工，明确谁在执行、代表谁、由谁负责。访问范围还要结合企业边界、员工已有权限和本次同意核对；人员调岗、任务结束或 Agent 停用时，相关访问也应有相应的调整路径。

业务操作：让一次指令落实为有边界、可核对的动作。 更新跟进时间与改变客户信用额度，应使用不同的执行规则。流程在必要处检查资源、操作和参数，安排人工确认，管理连接凭证，再用下游回执核对结果。授权、确认、工具调用和实际记录要能关联，便于异常处理和后续追溯。

企业 Context：让业务背景持续更新，并在需要时进入应用。 一端衔接业务数据与上下文服务，另一端衔接上下文服务与使用它的应用、Agent。增量更新、来源关联、权限变化和任务范围，都属于这条供给链路需要处理的工作。Context 的自动化供给，是平台在这一环节的建设重点。

这些准备还会支持团队持续积累协作资产。新增一个客户跟进 Skill，可以使用已有工具与获准访问的背景；调整一条 Workflow，可以沿用稳定连接与确认步骤。接口、身份与供给链路由平台侧维护，任务方法由业务团队完善，新使用者仍使用自己的授权。

Ready for Agent 描述的是一套逐段建设、逐项验收的准备工作。具体实现取决于部署版本、目标系统与完成的适配；以真实任务检查信息是否及时、权限是否恰当、动作是否落地，才能判断准备到了哪一步。

让 Agent 试用，成为企业“智-人”的新起点

回到这次客户跟进：销售沿用企业账号进入工作台，Agent 获得与任务相关的客户背景，同事补充判断，确认后的安排写入业务系统。下一次接手的人，又可以使用更新过的 Context 和团队验证过的 Skill、Workflow，继续推进工作。

从试用一款 Agent 平台，到让人与 Agent 在企业中持续协作，需要逐步接好这些环节。身份让员工进入熟悉的工作入口，应用连接让 Agent 使用现有业务能力，Context 供给帮助它理解当前情况，执行流程则把共同作出的决定落实为可核对的结果。

数犀集成平台的价值，体现在这些衔接之中。业务团队持续完善判断与工作方法，平台团队维护共用的身份、连接和运行机制，人与 Agent 才能围绕同一项任务接力，并把每轮协作的成果留给下一轮使用。这样的持续积累，为企业逐步构建 AI native 业务流程提供了基础。

可以先从一个客户跟进、项目交接或工单处理任务开始，把入口、信息、确认、执行和结果回流完整走通。然后请另一位同事实际接手，看看哪些材料还需要重复寻找，哪些背景还需要重新解释，哪些步骤仍容易中断。这些具体卡点，就是下一轮优化的起点。

当下一位同事能够带着已有的背景和方法，更顺畅地与 Agent 继续工作，平台试用才开始转化为企业可以持续积累的协作能力。