Workspace Agent改变了这个前提。

当一个Agent可以被整个团队共享，可以持续执行固定流程，可以读取企业数据、调用应用动作，并把结果交给下一位同事时，它就不再只是一个高级提示词。

它开始接近一个真正的数字化岗位。

企业需要管理的问题也随之改变：

谁负责设计这个Agent？
它可以访问哪些数据？
哪些动作能够自动执行？
出错以后由谁停止？
工作流改变以后由谁更新？
怎样证明它持续产生正确结果？

这就是Agent Operating Model，也就是企业Agent运营模式。

它不是一份简单的使用规范，而是一套围绕Agent所有权、权限、测试、发布、监控和持续改进建立的长期机制。

一、GPT和Workspace Agent有什么根本区别？

传统GPT更像一个可以重复使用的知识助手。

它通常包含：

• 固定的角色说明；

• 一组知识文件；

• 一套回答风格；

• 若干可调用工具。

用户发起问题后，GPT完成回答，任务通常在当前会话内结束。

Workspace Agent则更接近一个完整工作流。

它除了需要理解问题，还可能：

• 从多个企业数据源收集信息；

• 按照固定步骤做判断；

• 在连接的应用中执行动作；

• 请求人工确认；

• 输出结构化结果；

• 被多个团队成员重复调用；

• 通过定时、事件或接口持续运行。

两者最大的差异不是模型能力，而是责任范围。

GPT主要对一段回答负责。

Workspace Agent开始对一个流程结果负责。

一旦Agent开始创建工单、更新系统、发送通知、审批请求或写入业务数据，企业就不能继续按照“一个好用的聊天机器人”来管理它。

二、为什么共享Agent必须有明确Owner？

很多企业Agent在试验阶段都由某位积极员工创建。

最初效果很好，大家开始转发、复制和共享。几个月后，创建者调岗，业务流程发生变化，Agent仍然按照旧规则运行。

团队这时才发现，没有人能够回答：

• 当前提示词是谁维护的；

• 数据源为什么这样配置；

• 哪些动作经过批准；

• Agent失败后应该找谁；

• 新业务规则应该由谁更新。

所以每一个进入正式使用的Workspace Agent，都必须有明确Owner。

Owner不一定亲自维护全部内容，但必须对最终结果负责。

至少需要三类负责人。

业务Owner

负责定义：

• Agent解决什么业务问题；

• 哪些规则拥有最终解释权；

• 什么结果可以接受；

• 哪些情况必须交给人工。

技术Owner

负责维护：

• Agent指令；

• 工具与应用连接；

• 数据格式；

• 权限设置；

• 测试集；

• 版本与故障修复。

风险Owner

负责确认：

• 数据访问是否合规；

• 高风险动作是否需要审批；

• 日志中保存哪些信息；

• 出错后的暂停和回滚机制。

小团队中，一个人可以同时承担多个角色，但这些责任不能消失。

三、为什么提示词不能成为唯一运行规则？

个人使用ChatGPT时，很多要求可以直接写在提示词中：

优先检查公司政策。
信息不完整时不要批准。
涉及高金额申请时交给主管。

但当Agent开始承担共享流程后，仅靠提示词存在三个问题。

第一，规则不容易审计

业务负责人无法快速判断哪些规则已经生效，哪些只是创建者临时写下的描述。

第二，规则容易漂移

不同版本的Agent可能使用不同提示词，团队却认为它们执行的是同一套政策。

第三，提示词不能替代真实权限

写一句“不要删除数据”，不等于系统真的阻止Agent执行删除动作。

因此，企业需要把规则分成三层。

业务政策层

说明组织允许什么、不允许什么。

例如软件采购政策、费用标准和审批权限。

Agent执行层

说明Agent怎样收集信息、判断条件和输出结果。

系统控制层

通过应用权限、角色控制和人工批准，限制Agent实际能够执行的动作。

成熟的治理不是提醒Agent“请谨慎”，而是让高风险动作在系统层面无法被静默执行。

四、Workspace Agent需要怎样的权限模型？

一个共享Agent通常同时涉及三类权限。

数据读取权限

Agent能够读取哪些文件、邮件、工单、客户记录或内部文档？

原则应该是：

只提供完成当前职责所需的最小数据范围。

一个负责整理销售会议的Agent，不应该默认访问薪酬资料；一个负责创建软件申请工单的Agent，也不需要读取完整财务系统。

应用动作权限

Agent在连接的应用中可以做什么？

例如：

• 搜索；

• 读取；

• 创建草稿；

• 创建正式记录；

• 更新状态；

• 删除内容；

• 发送消息。

读取权限和写入权限必须分开设计。

能查看工单，不代表可以关闭工单；能生成邮件草稿，也不代表可以直接发送。

使用者权限

哪些成员可以调用这个Agent？

有些Agent可以向整个工作区开放，有些只能分配给特定团队、角色或小组。

共享范围越大，输入差异越大，误用风险也越高。

因此，Agent上线前应该形成一张权限矩阵：

权限对象	允许范围	限制
使用者	IT与采购团队	其他成员不可调用
数据	软件目录、员工目录	不读取薪酬与个人隐私
动作	创建申请草稿	正式提交需要人工确认
通知	申请人与审批人	不向公共频道发送
管理	Agent Owner	普通用户不可修改配置

五、Agent为什么必须有人工审批节点？

Agent能够执行更多动作，并不意味着所有动作都应该自动完成。

可以把动作分成三级。

低风险动作：自动执行

例如：

• 查询公开或授权资料；

• 整理信息；

• 生成摘要；

• 分类请求；

• 创建内部草稿；

• 提醒缺少材料。

这些动作即使出错，通常也容易纠正。

中风险动作：执行后可追踪

例如：

• 创建内部工单；

• 更新非关键状态；

• 向指定团队发送通知；

• 填写结构化记录。

需要保留执行日志、来源信息和回退方式。

高风险动作：必须人工批准

例如：

• 批准采购；

• 开通生产权限；

• 删除数据；

• 对外发送正式信息；

• 修改客户或财务记录；

• 执行付款；

• 关闭安全事件。

人工审批不应该只出现在流程最后。

如果Agent需要扩大数据范围、改变判断规则或执行计划之外的动作，也应该暂停并请求确认。

六、上线前为什么要建立测试集？

很多Agent的上线标准是：

我试了几次，看起来不错。

这对个人助手也许勉强够用，对企业共享Agent远远不够。

正式Agent至少需要一组代表性测试案例。

以软件申请审核Agent为例，测试集应该包括：

• 信息完整的标准申请；

• 缺少部门主管的申请；

• 已经存在同类工具的申请；

• 涉及敏感数据的工具；

• 超出预算上限的申请；

• 输入内容前后冲突；

• 申请人试图绕过政策；

• 无法找到可靠政策依据；

• 同一个申请被重复提交。

每个案例都需要预期结果：

案例：
员工申请一款未进入批准目录的云盘工具。

预期行为：
1. 识别工具可能存储企业数据；
2. 检查是否存在已批准替代品；
3. 不自动批准；
4. 要求补充数据类型和使用场景；
5. 创建安全审查草稿；
6. 等待人工确认后提交。

测试Agent不能只检查最终答案像不像人写的。

还要检查：

• 是否访问了正确数据源；

• 是否遵守权限边界；

• 是否漏掉审批节点；

• 是否产生不允许的动作；

• 是否能够解释判断依据。

七、完整案例：软件申请审核Agent怎样运行？

假设企业经常收到员工申请新软件的请求。

传统流程是：

员工填写表单
→ IT检查已有工具
→ 安全团队评估数据风险
→ 采购检查预算
→ 主管批准
→ IT创建安装工单

流程跨越多个团队，员工经常不知道进度，审核人员也要反复收集相同信息。

Workspace Agent可以负责其中的协调工作。

第一步：接收申请

Agent收集：

• 申请人；

• 部门；

• 软件名称；

• 使用目的；

• 用户数量；

• 数据类型；

• 预计费用；

• 期望使用时间。

信息不完整时，只提醒补充，不继续执行。

第二步：检查现有目录

Agent查询企业已经批准的软件目录，判断是否存在功能相同的工具。

如果已有替代品，输出比较结果，并让申请人说明为什么不能使用现有方案。

第三步：执行政策判断

Agent根据软件采购政策判断：

• 是否超出部门预算；

• 是否涉及个人数据；

• 是否需要安全评估；

• 是否需要法务审查；

• 审批链应该经过哪些角色。

Agent只能根据已批准政策判断，不能自行创造新规则。

第四步：生成审核草稿

Agent输出：

申请摘要：
已有替代方案：
预算判断：
数据风险：
需要的审批人：
缺失材料：
建议下一步：

第五步：人工批准

对于低成本、无敏感数据且已有标准合同的软件，可以由指定人员快速确认。

涉及客户数据、代码仓库、生产系统或高金额采购时，必须进入安全、法务或采购审批。

第六步：创建工单

人工确认后，Agent才在工单系统中创建正式记录，并通知申请人与审批人。

第七步：持续跟踪

Agent可以定期整理：

• 等待申请人补充的请求；

• 等待安全审核的请求；

• 即将超过处理时限的请求；

• 已完成但尚未通知申请人的请求。

在这个案例中，Agent承担的是信息收集、政策匹配和流程协调。

最终决策仍由拥有权限的人完成。

八、Agent出错以后，企业应该怎样处理？

Agent进入正式流程后，企业需要像管理线上服务一样管理异常。

常见事故包括：

• 引用了过期政策；

• 向错误人员发送信息；

• 创建重复工单；

• 错误判断审批路径；

• 连接应用权限扩大；

• 数据源内容发生变化；

• Agent更新后成功率下降。

每个Agent都需要预先定义停止条件：

以下情况立即暂停自动执行：

1. 找不到有效政策依据；
2. 输入之间存在明显冲突；
3. 需要访问未授权数据；
4. 准备执行高风险动作；
5. 连续两次执行失败；
6. 输出结果无法通过验证；
7. 应用权限或数据源发生变化。

还要明确事故处理流程：

暂停Agent
→ 保留执行记录
→ 确认影响范围
→ 修复规则或连接
→ 用历史案例回归测试
→ 重新审批后发布。

“提示词改了一下”不能直接成为重新上线的理由。

九、怎样管理Agent版本？

共享Agent一旦进入正式使用，就不应该在没有记录的情况下随意修改。

每次更新至少记录：

• Agent版本；

• 修改负责人；

• 修改原因；

• 指令变化；

• 数据源变化；

• 权限变化；

• 测试结果；

• 回滚方式；

• 生效日期。

例如：

Agent：Software Request Agent
Version：1.4
Change：
新增敏感数据识别规则；
未批准工具必须进入安全审核；
取消自动创建正式工单。

Test：
32个标准案例全部通过；
2个边界案例需要人工接管。

Rollback：
恢复到1.3版本配置。

版本管理的目标不是增加文档工作，而是让团队知道：

当前运行的Agent到底遵循哪套规则。

十、Agent运营应该看哪些指标？

只看调用次数，会让团队误以为使用越多越成功。

Agent Operating Model应该至少关注六类指标。

任务完成率

多少请求真正完成了预期流程？

首次成功率

有多少任务不需要重新执行或人工纠正？

人工接管率

多少任务因为规则不清、权限不足或异常而交给人工？

人工接管不是一定越低越好。高风险流程保留合理接管，反而说明控制有效。

平均处理时间

Agent是否真的缩短了流程，还是只是增加了新的等待节点？

错误动作率

出现错误写入、错误通知、重复工单或越权尝试的比例。

单次有效交付成本

每个成功完成的任务消耗多少资源？

最终看板可以是：

总请求数：
成功完成：
需要补充信息：
人工接管：
执行失败：
平均处理时间：
高风险审批次数：
重复或错误动作：

十一、Agent Owner责任矩阵

可以使用下面的责任分工：

工作内容	业务Owner	技术Owner	风险Owner	使用团队
定义业务目标	负责	参与	参与	提供反馈
编写工作流程	确认	负责	审查	试用
配置数据源	确认	负责	批准	不参与
配置应用动作	参与	负责	批准	不参与
建立测试集	负责业务案例	负责执行	负责风险案例	提供真实样本
发布Agent	批准	执行	批准	使用
处理故障	判断业务影响	修复	判断风险	报告问题
定期复盘	负责	提供数据	审查异常	提供反馈

无论团队使用什么名称，必须保证每项关键责任都有明确归属。

十二、Workspace Agent上线检查表

□ Agent只负责一个清晰的业务流程
□ 已确定业务Owner、技术Owner和风险Owner
□ 指令与业务政策分开维护
□ 每个数据源都有明确用途
□ 数据权限遵循最小必要原则
□ 读取和写入权限已经分开
□ 高风险动作必须人工批准
□ 已建立标准、异常和攻击性测试案例
□ 每项测试都有预期结果
□ Agent输出包含依据和待确认项
□ 执行动作拥有日志和回退方式
□ 已定义停止条件
□ 已建立版本记录
□ 已建立故障暂停和恢复流程
□ 已确定运营指标和复盘周期
□ 使用者知道Agent能做什么、不能做什么

十三、企业怎样从一个Agent开始？

不要一开始就建设覆盖整个公司的“超级Agent”。

更稳妥的顺序是：

第一阶段：选择一个重复且边界清楚的流程

例如：

• 软件申请整理；

• 销售会议准备；

• 工单分类；

• 周报汇总；

• 标准文档检查。

第二阶段：先让Agent只读

先完成信息收集、分类和草稿生成。

确认稳定后，再逐步开放写入动作。

第三阶段：保留人工确认

让Agent负责准备结果，人类负责批准关键动作。

第四阶段：建立测试和指标

连续运行两到四周，记录真实成功率、人工接管率和异常类型。

第五阶段：再扩大共享范围

只有当流程、权限和Owner都稳定以后，才应该开放给更多团队。

结语

从GPT到Workspace Agent，真正发生的变化不是界面多了一个Agent入口。

而是AI开始从“回答个人问题”，走向“承担团队流程”。

当一个Agent能够访问企业数据、跨应用执行动作，并被大量成员共享时，它就需要具备和正式业务系统类似的运营机制：

有明确Owner；
有最小权限；
有测试标准；
有人工审批；
有版本记录；
有运行指标；
有故障暂停和回滚能力。

企业不能只讨论Agent能做什么，还必须提前决定：

Agent做错以后，谁负责？

这正是Agent Operating Model存在的原因。

未来企业之间的差距，可能不只是有没有部署Agent，而是谁能够把Agent从一次性演示，变成一个稳定、可审计、可持续改进的生产系统。