WorkBuddy 怎么接企业系统：办公入口与后台工作流的分工

把 WorkBuddy 接入企业系统，不应理解为让办公入口直接拥有后台全部能力。入口擅长接收自然语言、整理上下文、展示计划和收集确认；后台工作流负责稳定规则、身份校验、事务处理、审计和重试。两者通过清晰契约连接，才能既保留办公效率，又不把核心系统暴露给不可预测的输入。凡是涉及订单、客户、财务或权限数据的动作，都应由后台再次校验，而不是信任入口已经判断正确。

判断这个场景是否适合

先判断企业系统是否有受支持的接口。稳定 API、消息队列或经过治理的自动化入口，适合形成长期集成；依赖页面坐标和临时脚本的操作容易因界面变化失败，只适合作为受控过渡方案。接口应能返回业务标识与明确状态，支持查询结果，写操作最好具备幂等或撤销机制。无法判断请求是否成功的系统不适合自动重试。

第二步识别任务归属。查余额、搜制度和读取工单属于只读查询；创建草稿、预填表单属于可确认的准备；提交审批、修改主数据和发送通知属于业务写入。前两类可以在入口提供较即时体验，写入类则应进入后台队列、规则校验和审批。若一个请求混合多类动作，必须拆开显示并分别授权。

第三步核对身份链。需要决定以用户身份委托，还是使用受限服务账号。用户委托便于继承原权限，但令牌范围与有效期要受控；服务账号适合固定流程，却不能成为绕开个人权限的通道。后台要根据用户、部门、数据范围和动作再次鉴权，入口传来的角色文字不能作为可信凭据。

适用性还取决于验收和对账。集成成功不能只看接口返回，而要验证目标系统产生了正确业务状态，下游任务没有重复，并能由人员查询。对于旧系统，如果缺少测试环境、日志和稳定标识，应先补充适配层，或把自动化停在生成操作清单，由人员在原系统完成。

实施时怎么拆

首层是入口契约。定义用户可表达的意图、必填字段、允许来源和结果展示。自然语言解析后生成结构化请求，字段缺失或冲突时追问，不用猜测补全关键数据。入口展示即将执行的系统、账号、对象和动作，高风险请求要求再次确认，确认结果带签名和有效期传入后台。

第二层是集成网关。统一处理鉴权、限流、字段校验、敏感数据遮蔽、幂等键和审计。每个连接器只获得所需接口和数据范围，生产与测试凭据隔离，密钥不进入提示词或日志。网关将外部错误转换成明确状态，区分可重试、需人工处理和永久拒绝，避免入口对所有失败重复调用。

第三层是后台工作流。业务规则、审批链、事务和补偿在确定性环境执行。需要多人批准时，WorkBuddy 可以提醒和汇总，但不能代替审批者。长任务返回受理编号，使用者可以查看状态；部分成功要列出明细。后台发布新版本前用沙箱数据验证正常、重复、超时、越权和回调乱序。

第四层是端到端验收。业务人员从入口发起代表性请求，核对结构化计划、审批、后台状态、通知和最终数据；安全人员测试跨部门和过期令牌；运维验证告警、队列和审计。发布采用小范围和可关闭开关，保留旧入口或人工路径。若出现重复写入、权限穿透或数据不一致，立即停止该连接器和新请求。

不要忽略的限制

入口、网关和后台可能由不同团队维护，版本变化会造成字段含义不一致。接口契约需要版本号、兼容期和负责人，不能在后台新增必填字段后让入口静默失败。模型生成的结构即使符合格式，也不证明业务含义正确，因此金额、对象、时间和范围等关键值仍要规则校验与人工确认。

回滚要分层处理：入口模板可切回旧版，网关可关闭路由，后台流程可回退版本，但已经提交的业务事务需按系统规则撤销或补偿。对超时状态不明的请求先查询和人工对账，禁止直接重放。事故复盘应关联入口记录、网关标识与后台业务号，确认影响范围后再恢复。只有分工、权限、验收和补偿链完整，办公入口才适合连接核心流程。