- 拖慢内部工作的，是大家在邮件、聊天群和多个版本的文件之间来回追问，步骤本身很少有难度。
- 好的系统先让每项工作都有状态、有负责人、有明确的下一步，然后才谈得上加入 AI。
- 有了这个基础，AI 才真正帮得上忙：读取申请、分类、收集资料，并在工作逾期之前发出提醒。
传统网站和应用做不到的地方
如果今天您想知道某位客户的申请卡在谁手上，就得翻群聊、找邮件，再打电话问另外两个人。这是流程看不见造成的，员工再勤快也解决不了。
企业有好几套系统，员工却仍然在聊天工具里追工作进度，因为每套系统只看得到自己那一段。跨部门的工作，从头到尾都没有一个负责人。
很多内部工作慢，是因为要在邮件、聊天工具、电子表格和好几套系统之间流转，单看其中任何一个步骤都不难。一个人不知道另一个人做到了哪里，于是有人问进度，有人重复发文件，问题靠私信临时解决。工作能往前走，靠的是某个人记性好，流程本身始终没人看得见。
写给开发团队 · 技术细节
AI 内部运营应用（AI Internal Operations App）应先让工作有清晰的 State、Owner、Dependency 和 Next Action，再增加智能。这样 AI 智能体（AI Agent）才能帮忙读取申请、分类、收集资料、发送提醒、为决策做准备，而不会变成一个消息越发越多、却没人知道正式 Record 在哪里的系统。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 接收表单，保存状态，显示仪表盘 | 智能体把申请拆成子任务，从多个系统调取数据，按服务水平协议（SLA）排定优先级，发起审批，并说明工作为什么卡住 |
只有当每个工作项（Work Item）都有唯一的状态和标识符时，智能体才能帮忙协调工作。工作流系统控制流转路径，AI 负责解读文字、准备数据。把这两种职责分开，可以防止一段自然语言回复在没有证据的情况下改动重要状态。
企业可以用上的新能力
加入 AI 之前要先解决的，是让每项工作都有明确的状态和负责人，就像工厂里的派工单。有了这一步，AI 才真正帮得上忙：读取新进来的申请，判断属于哪一类事务，把相关资料调出来附上，并提前提醒哪些事情快要逾期。
项目形态
系统就是一个运营工作台（Operations Workspace）：从表单、电子邮件或聊天工具接收申请，建立一个统一的工作项。所有相关人员看到的是同一条时间线、同一批文件、同样的负责人、SLA 和例外情况。AI 帮忙把杂乱的文字转成可以核查的数据，但在关键环节不会跳过人工确认。
应有的功能
功能可以包括智能接收、自动分类、重复检测、检查清单、审批、SLA 提醒、异常队列（Exception Queue）、状态摘要和跨系统更新。经理的界面应突出积压的工作、积压的原因和待做的决定，不要用好看却无法据此行动的汇总图表来代替。
背后的技术
系统的核心是工作流引擎（Workflow Engine）和状态存储（State Store），通过 API 和事件连接 ERP、HRIS、CRM、文档或邮件系统。AI 用于解读和总结；状态变更、权限和审批条件则使用可以明确定义的规则。系统必须具备队列、重试和幂等性（Idempotency），防止重复的指令生成重复的记录或重复付款。
对组织的好处
员工追进度、找文件的时间少了；主管能在工作超出 SLA 之前看到瓶颈；管理层能分辨问题出在产能不足、数据不全，还是审批规则。长远来看，协调人员脑子里的经验会变成可以传授、检查和改进的流程，同时仍为例外情况留出空间。
- 智能接收，把日常语言写的申请转成结构化数据
- 流程编排（Orchestration）借助统一的状态，协调跨系统、跨部门的工作
- 例外优先的界面设计，只把需要人来决定的事情呈现给人
- 流程学习，用日志找出瓶颈和需要修改的规则
模拟案例
实际使用场景
系统把开设新分店的申请拆分成 IT、采购、人事和行政后勤几项工作。智能体检查缺少哪些信息，按依赖关系创建任务，关键路径一旦延误就通知主管。
在一个模拟案例中，新增一家供应商要经过采购、财务、法务和预算负责人。系统读取申请，按供应商类型检查文件，为每个部门创建任务，并显示依赖关系。如果税号对不上，AI 会在转交之前先要求补充资料，减少各部门已经开始审核后再退回的情况。
遇到例外情况，比如需要紧急新增供应商，系统会把它分到例外通道（Exception Lane），注明原因、风险和有权审批的人，不会硬把特殊个案塞进常规流程。管理层由此看得出例外为什么频繁发生，以及应该在哪里调整制度或产能。
先定状态，再上智能体
加入 AI 之前，先定义状态、负责人和状态变更规则。
如果系统不知道工作进行到哪一步，智能体只会发出更多消息。
范围、风险与效果评估
写给开发团队 · 技术指标
没有 Idempotency、Permission 和 Manual Recovery 的自动化，会以极快的速度放大错误。应按阶段衡量 Cycle Time，以及 Waiting Time、Rework、Exception Rate 和仍需通过聊天工具催办的工作数量。如果系统关闭 Ticket 很快，员工却仍在系统之外干活，这个数字反映不了真实的 Productivity。
智能体在没有幂等性保护、权限和审计记录的情况下，不得修改重要数据。优先级排序必须透明，不得区别对待。
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
出现重复记录、状态卡住且没有负责人，或者员工经常要在系统之外修改数据时，就应暂停自动化。这类问题通常要先修好工作流和系统集成，再考虑增强模型的能力。
BUSINESS & PRODUCT READINESS
让智能体接手工作之前，先让状态、负责人和依赖关系看得见
写给开发团队 · 技术细节
Operations Agent 修不好一个没有负责人的流程。如果状态只有“处理中”一种，系统就分不清是在等数据、等审批，还是在等其他系统。所以要先建立 State Model、Entry/Exit Criteria 和 Dependency，再让智能体帮忙转换申请、管理队列、解释瓶颈。
写给开发团队 · 技术指标
根据真实个案准备 Exception Catalog，不要只为 Happy Path 做设计。为重复执行的 Action 定义 Idempotency，规定变更 State 的权限，以及 Integration 宕机时的 Fallback。衡量 Orphan Task 和 Exception Age，看工作有没有在部门之间丢失。
可以先为一类工作画出状态图，写明每个状态由什么事件触发进入、拿到什么证据才能离开、谁有权做决定。然后整理例外目录（Exception Catalog），区分哪些情况应该再设计一条流程，哪些情况必须由人来判断。
智能体只应获得其角色必需的权限，比如可以读取文件、起草申请，但审批或修改主数据必须做成单独的工具，并由专人确认。先从一个团队、一条业务流程开始，等数据质量和恢复机制可靠了，再连接整个组织范围的流程。
谁对整条流程的结果负责？
哪个状态最含糊？
哪些操作绝不能重复发生？
系统宕机时，工作卡在哪里？
让跨部门的工作只走一条路径，而且人人看得见
DNA Maker 先和流程负责人及一线执行人员一起绘制服务蓝图（Service Blueprint），跟着真实个案走一遍，直到接收、状态、交接、审批和例外都清清楚楚。在考虑自动化之前，我们会先帮忙砍掉没有价值的步骤，免得新系统只是把旧流程跑得更快，复杂程度却一点没变。
产品/UX 团队设计工作队列、例外视图和上下文面板，让每个角色看到足以做决定的信息。智能体放在需要读取非结构化数据、或要协调多个工具的环节，业务规则则放在可审计的工作流里。
DNA Maker 帮助把散落在聊天记录和个人记忆里的工作，整理成服务蓝图、状态模型、角色与权限，以及系统集成图。制度和例外仍由客户团队决定，我们负责让这些规则出现在员工真正会用的队列、审批和审计界面上。
我们可以开发内部 Web 应用、工作流引擎、AI 接收与协调功能、仪表盘和连接器，并提供可以修改规则和 SLA 的管理后台。试点会跟踪一个工作项从头到尾的全过程，分别衡量人工处理时间（Touch Time）和等待时间（Waiting Time），并与一线用户交流，弄清系统是真的减少了协调工作，还是只把负担挪到了另一个界面。
我们能开发内部 Web 应用、工作流引擎、AI 编排器、角色与权限、系统集成、通知和管理仪表盘，并内置审计、重试和监控。架构设计让各个组件可以在下一条业务流程中重复使用。
如果有某项跨部门工作，大家都靠聊天工具追进度，可以挑出一条业务流程，带上卡住的个案来聊。DNA Maker 会帮忙梳理现状流程和目标流程，并在全面投资平台之前，先做出工作队列的原型。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
表中的术语能帮助团队在谈状态、重复执行、SLA 和多系统协调时说的是同一件事。在把权限交给智能体之前，可以用这些术语检查工作流是否涵盖了常规路径、例外情况和恢复机制。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Orchestration | 控制多个步骤和多个系统协同工作。协调层必须知道每一步的状态、依赖关系和失败情况，才能暂停、重试或转交给人，而不用把整个流程从头再来。 | 按依赖关系推进开设分店的各项工作 | 谁对整条流程负责？ |
| State Machine | 规定工作如何变更状态的规则。状态机（State Machine）把状态和转换路径定义清楚，防止工作跳过步骤，或卡在没有负责人的状态里。 | 草稿 → 审核中 → 已批准 | 状态改错了能不能退回？ |
| Idempotency | 防止重复的指令产生重复的结果。系统在超时（Timeout）后重试指令时，这条原则尤其重要，可以避免重复创建采购单或重复扣款之类的问题。 | 重试后不会生成两张采购单（PO） | 所有重要操作都做了防重复处理吗？ |
| SLA | 约定的服务时间。SLA 应衡量对服务对象有意义的时间，把等待资料的时间和实际处理的时间分开，并写明超时后会发生什么。 | IT 部门在 4 小时内受理工作 | 快要超出 SLA 时通知谁？ |
| Workflow Engine | 执行工作规则和流转路径的系统。引擎保存规则、状态、待办任务和交接，修改流程时不必把所有条件都硬编码在界面或提示词（Prompt）里。 | 按金额发起审批 | 谁有权修改规则？ |
延伸阅读（原始文档）：https://openai.github.io/openai-agents-js/guides/multi-agent/