导入 AI Orchestration Agent 前：先画清楚工作指挥图
一个客户在 WhatsApp 问订单状态，客服同事想用 AI 快速回复。AI 先查客户关系管理系统(CRM)，再查物流状态，发现货件延误，又建议补寄优惠券。问题来了：AI 可否直接查所有客户资料？可否自动承诺补偿？谁批准？最后要写回哪个系统？
这就是 `AI Orchestration Agent` 真正要处理的问题。它不是另一个聊天机器人，而是公司用来指挥多个 AI Agent、业务系统、人工审批和审计记录的控制层。对香港中小企业来说，重点不是一次过买齐所有 AI 工具，而是先画清楚一张“工作指挥图”：每类请求由谁接、AI 做哪一步、人在哪里审批、系统在哪里留记录。
2026 年 6 月 25 日，OpenAI 发布有关 agents 如何进入工作场景的研究；同日 Axios 也报道，Codex 类代理工具正在由简单查询走向更长时间、更复杂的委派工作。相关研究亦指出，部分使用者已同时管理多个代理，并用 skills 保存复杂工作指令。这些信号很清楚：AI 正在由“帮我写一句”变成“帮我跟完整件事”。一旦 AI 可以跟完整件事，企业就要先决定谁指挥。
一句定义：Orchestration Agent 是工作路由，不是万能员工
AI Orchestration Agent 可以理解为一个工作路由和管控层。它负责接收请求、分类、分派、检查权限、触发审批、记录结果，再把资料写回正确系统。
它不一定亲自完成所有工作。比较健康的设计，是让不同专门代理各做一段：
客服代理：整理查询、草拟回复、分类投诉。
销售代理：根据 CRM 和产品资料准备跟进内容。
财务代理：按规则计算退款、折扣或对账差异。
文件代理：摘要合同、表格或客户提交资料。
报表代理：整理每日或每周异常。
软件代理：准备代码修改、测试和发布说明。
Orchestration Agent 的工作，是决定这些代理何时出手、可读取什么资料、可写回什么位置、哪一步必须由人批准。
培训中心例子：企业客户查询 30 人课程。Orchestration Agent 先判断是 B2B 报价；销售代理草拟方案；排班代理检查讲师时间；财务代理计算公司客户折扣；如折扣超过指定门槛，就送主管审批；批准后才写回 CRM、预约系统(Booking System)和销售 pipeline。这样才是一条可管理的 AI 工作流。
第一层：把请求分类，避免所有事都丢给同一个 AI
很多公司试 AI 时，会先建一个“公司 AI 助手”，什么都问它。这对内部试用很方便，但一到真实运营就容易混乱。客服问题、退款问题、系统问题、合同问题和管理报表问题，风险完全不同，不应走同一条路。
工作指挥图的第一层，是把请求分成清楚类别。
零售例子：同一句“我收不到货”，可能是一般查询、物流延误、地址错误、付款异常，也可能是投诉。Orchestration Agent 应先分类：一般查询可由客服代理草拟回复；物流延误要建立 ticket；付款异常要通知财务；投诉升级要交主管。这样前线同事不用每次重新判断，管理层也知道哪类问题最多。
专业服务例子：客户问“合同可否改这一条？”文件代理可以找出相关条款，但 Orchestration Agent 应判断这是法律/商务风险，不可自动回复。它可以准备摘要，然后送负责顾问或主管确认。
第二层：把资料权限拆细，不要给 AI 一把总钥匙
AI Agent 最危险的地方，不一定是答错，而是拿到太多权限。为了 demo 好看，团队很容易把整个 CRM、共享云端硬盘、客服对话和报表都接上 AI。结果是每个代理都看得太多，也做得太多。
Orchestration Agent 应把权限拆成四级：
只读参考资料：产品介绍、FAQ、公开政策、标准流程。
读取指定个案资料：某一位客户、某一张订单、某一个项目的文件。
低风险写入：新增内部备注、建立待办、分类 ticket、更新标签。
高风险动作：发正式通知、批准退款、改合同、改价格、部署系统。
物流例子：AI 可以读取某张运单和客户查询记录，但不应读取全公司所有客户资料。它可以草拟延误回复，但不可自行承诺赔偿。它可以建立内部跟进 ticket，但退款必须经主管或财务批准。
软件团队例子：AI coding agent 可以读取指定 repo 和任务编号，可以开 pull request，但不可直接合并到主分支，更不可直接部署生产环境。Orchestration Agent 要在任务系统、代码审查和持续集成/持续部署(CI/CD)之间加上清楚关口。
第三层：审批点要写成规则，不要靠人记得
很多企业其实有审批文化，只是没有把它写入系统。退款要问谁、折扣要问谁、客诉要问谁、系统上线要问谁，通常靠同事记得。当 AI 加入流程，靠记忆会更危险，因为 AI 会把事情做得更快。
Orchestration Agent 应把审批点变成可执行规则。
客服例子：客户要求退款。AI 可以先查付款记录、订单状态、过往投诉和公司政策，然后生成三个建议：拒绝、部分退款、全额退款。但只要金额超过指定门槛，或者客户一年内已有多次退款，系统就要送主管审批。
教育例子：学员想转班。AI 可以查名额、付款和出席记录。同价转班可由前台确认；涉及退款、保留学位或企业客户合同条款，就要送行政主管审批。
管理报表例子：AI 每星期整理销售和客服摘要。若只是内部草稿，可以自动生成；如果要发给董事或外部投资者，就必须由管理层确认数据来源和口径。
第四层：审计记录要讲得出“为什么”
如果 AI 只留下最后答案，企业其实没有真正控制流程。日后客户追问、主管复盘、合规检查或系统出错时，公司需要知道每一步为何发生。
一条可用的 AI orchestration workflow，至少应保存这些记录：
请求来源：客户、同事、系统提醒或管理层指示。
使用资料：读取了哪个系统、哪个文件、哪段时间的资料。
代理分工：哪个代理做分类、摘要、计算、草拟、检查。
触发规则：例如金额门槛、客户等级、风险分类、SLA 超时。
人工审批：谁批准、何时批准、批准什么。
系统写回：更新了 CRM、客服 ticket、预约系统、报表或文件库哪个位置。
例外处理：哪一步失败、由谁接手、如何补回记录。
例如客服主管每星期看报表，不应只看到“AI 处理了 300 个查询”。更有用的是：多少个自动完成、多少个转主管、多少个涉及退款、多少个因资料不足要人工跟进、多少个超过服务水平协议(SLA)。这些数字才可以帮公司改善人手、系统和客户承诺。
第五层：备用方案不是换模型，而是保留公司流程
AI 工具会更新、限流、改价、停用某些功能，甚至因政策或供应商安排而改变可用范围。企业不能把整条流程锁死在单一平台。
Orchestration Agent 的设计应保留三个备用点。
第一，资料仍留在公司系统。CRM、订单、发票、ticket、报表和审批记录，不应只存在 AI 平台里。
第二，规则可被人读懂。退款门槛、客户分级、升级条件、资料权限，不应只藏在一段 prompt 里，应整理成公司可维护的规则。
第三，人工可以接回流程。当 AI 工具不能用，前线同事仍应知道下一步：查哪个系统、用哪个模板、谁审批、如何补回记录。
例如一间电商公司让 AI 处理退货查询。即使 AI 暂停服务，客服仍可在 CRM 看到退货规则、客户记录和待审批事项，而不是要从头翻查聊天记录。
30 日内可以这样开始
第一星期，选一条流程，不要选全公司。建议由客服查询、销售跟进、退款审批、预约改期、每周管理报表或软件发布流程入手。标准是高频、规则清楚、风险可控。
第二星期，画出工作指挥图。用表格列出：输入来源、资料系统、AI 可做的步骤、人工审批点、系统写回位置、例外处理方法。
第三星期，拆权限。决定哪些代理只可读取资料，哪些可建立草稿，哪些可写入内部记录，哪些永远不能自行做高风险动作。
第四星期，小规模试行。先选一个部门、一类查询或一批内部个案。量度四件事：处理时间、人工接手比例、错误原因、记录是否足够。不要只问“有没有更快”，也要问“出事时是否查得清”。
最后要问的不是“用哪个 AI”，而是“谁指挥工作”
AI Orchestration Agent 的价值，不在于让 AI 变成万能员工，而是让 AI 在公司可控的工作流内做事。当多个 AI Agent 开始连接 CRM、预约、客服、财务、文件、报表和开发工具，真正的竞争力会来自流程设计：资料边界清楚、审批点清楚、记录清楚、例外有人接手。
管理层可以先问一个很直接的问题：如果明天 AI 帮公司处理一宗退款、一份报价、一个投诉或一次系统修改，谁会知道它用了什么资料、跟了哪条规则、谁批准、最后写回哪里？
如果这个答案讲不清楚，暂时不要急着扩大 AI Agent。先把工作指挥图画出来，才是导入 orchestration agent 的第一步。
规划实施项目
明确系统间的数据流向、审批环节和异常处理责任，再规划接口与自动化流程。