第八章 Agent 组织与实施路线

本页目录

• 8.1 最小实施团队与经营责任
• 8.2 人机分工与协作机制
• 8.3 知识 流程与评估资产
• 8.4 账号 权限与运行底座
• 8.5 完整成本与投资评审
• 8.6 90 天路线图与阶段验收
• 8.7 编排平台与毕业方案
• 三类企业的实施起点
• 本章实战与最终验收

企业获得一项可运行的 AI 能力，需要有人定义业务结果，有人交付系统，也有人持续维护资料与流程。岗位数量、Agent 数量与实际经营能力没有固定对应关系。本章将前七章的业务成果组合成组织、架构、投资与实施方案。

学习后，应能够指定结果负责人，设计人机职责与升级机制，核算完整成本，并提交一份有阶段验收和退出条件的 90 天路线图。企业可以根据实际条件调整周期，不能按固定日程承诺所有场景同时上线。

8.1 最小实施团队与经营责任

最小团队必须具备经营授权、业务判断、实施与持续运营四类职责，可以由少量人员兼任，但不能缺失。经营授权者决定方向、预算和重要取舍；业务负责人定义流程与合格结果；实施负责人交付集成、可靠性和控制；运营责任人维护知识、任务、异常和质量。

负责人需要掌握真实业务，能够提供样本、确定标准和推动使用。如果只指定一名对业务没有决策权的“AI 联络员”，项目可能长期等待资料和审批。授权应写清能够决定什么，哪些事项需要更高层确认。

实施职责包含数据、接口、模型、工具、发布和运维，不必全部由单人完成。无 IT 团队的企业可以由外部技术办公室承担统一技术责任；小型 IT 团队可以补齐产品、数据或 AI 工程；成熟团队则需要公共能力与跨团队治理。组织方式由现有能力决定。

业务部门不能只提需求然后等待验收，技术团队也不能独自定义业务正确性。双方共同整理流程与评估样本，明确错误影响和处理。上线之后仍需保留固定运营时间，不能把维护放在“有空再做”。

岗位调整应以实际任务变化与能力培养为依据。自动生成初稿后，员工可能需要更多核验、判断、协调和例外处理。人员减少不是课程的固定目标，岗位重新设计与经营效果应分别说明。

8.2 人机分工与协作机制

所谓“一个操盘手加多个 Agent”只是一种形象表达，正式设计需要任务、权限、交接、责任与容量。一个人无法无限审核所有结果、维护全部系统或承担所有异常。设计前估算审核和运营工作量，保留备份责任人与服务安排。

职责表可以使用负责执行、最终负责、参与咨询和知会四类角色，通常简称 RACI。每项重要结果有明确最终责任，执行步骤可以分配给不同员工、系统或 Agent。Agent 执行不改变人的经营责任。

业务与技术每周检查四项内容：指标是否变化，失败发生在哪一步，资料与权限是否需要修改，下个周期完成什么。会议产生的任务记录负责人、依据、完成条件和期限，不能只保存一份 AI 会议摘要。

绩效应鼓励真实反馈与知识贡献。员工发现错误并正确升级，不应因自动化率下降受到惩罚；否则问题会被隐藏。业务改善、质量、使用与风险共同评价，避免团队为提高调用次数或关闭工单数量而偏离目标。

协作设计还需考虑业务例外。销售已经进入谈判，开发 Agent 暂停；客服人工接管后，自动回答暂停；广告负责人手动修改预算后，旧建议失效。人机之间共享状态和停止规则，才具有清楚交接。

相关组织方法可参阅企业 Agent 落地指南 第十九章。本课程要求将这些职责具体映射到市场、内容、销售和客服，不停留在岗位名称。

8.3 知识 流程与评估资产

能力资产包括数据口径、产品与政策知识、系统接口、流程、提示词、真实素材、评估样本、授权规则和运行记录。它们分别有版本、责任人和更新机制，不能散落在员工个人账号和聊天历史中。

提示词记录用途、输入要求、适用范围、输出结构和已知失败；知识记录来源、有效范围和确认；工具记录账户、资源、权限和返回状态；流程记录触发、分支、审批、异常与恢复。把这些资料组合起来，其他人员才能接手维护。

评估资产从真实工作中形成。选取代表性任务，保存脱敏输入、允许资料、期望结果、允许动作、禁止动作与评分规则。普通任务验证基本能力，边界任务验证缺失或冲突处理，失败任务验证是否正确升级。只测试已知简单问题，会高估正式运行效果。

每次改模型、提示词、知识索引、接口或流程，按影响范围运行回归评估。业务答案允许多种合理表达，但关键事实、操作边界和业务完成条件必须稳定。不能要求模型逐字复现旧答案，也不能仅凭语义相似判断交易动作正确。

验收采用业务、质量、运行与风险四组证据。业务看真实结果及基线；质量看事实与任务完成；运行看延迟、成本与失败恢复；风险看权限、隐私、审批与审计。重大越权、错误商务承诺或客户数据泄露应作为独立失败项，不能用平均高分抵消。

上线后保存可追溯但必要的日志，敏感信息脱敏并限制访问。日志可以说明任务、输入版本、资料、工具、状态、审批与结果，无需把所有客户信息长期复制到每个系统。失败进入评估集，修正后验证是否同时影响其他任务。

真实案例 DBS 的跨职能协作

DBS 在 2024 年年报董事长与 CEO 信中介绍，围绕客户旅程组织横向跨职能团队，并以实时数据推进改善。风险负责人说明，数据管理办公室牵头形成生成式 AI 的端到端风险与控制评估方法。年报管理层说明、风险负责人说明

该案例来自银行，监管、规模与业务模式不同于外贸和跨境企业。可借鉴的是围绕客户任务组织协作、明确数据与风险责任；不能把银行的模型规模与经济收益套到小企业。出海企业可以从一条询盘或订单旅程落实相同组织原则。

8.4 账号 权限与运行底座

Agent 运行底座需要管理身份、上下文、工具、状态、重试、停止、观测和控制。模型负责理解与生成，系统负责真实权限和动作约束。企业的 CRM、订单与广告接口应只开放当前任务必要能力。

权限按主体、资源、动作和条件定义。例如客服 Agent 可以读取当前已验证客户的订单，销售 Agent 可以创建草稿与任务，广告分析 Agent 只读指定账户。对金额、市场、产品、时间和频次的限制写在执行层，不依赖模型自行遵守。

建立环境隔离，测试数据与生产数据分开，测试账号不具备真实退款、群发和无限调整预算权限。对不可逆或重大动作，先形成具体请求与审批，工具核对批准对象、版本、有效期与当前状态，再执行。

密钥与账号归企业管理，采用专用服务身份和最小权限，避免员工离职后能力失效或无法追责。凭证不放在提示词、内容文件或可公开日志。外部供应商访问有范围、期限和退出安排。

输入资料中的网页、邮件、评论与附件只是待处理内容，不能成为新的系统指令。测试应包含诱导泄露数据、要求绕过权限和伪造批准的输入，检查工具是否真正阻止。过滤文字只能降低部分风险，接口隔离仍然必要。

运行设计设置超时、调用预算、最大步骤、幂等、失败队列与告警。任务状态至少分为待处理、处理中、待确认、执行中、完成与失败，必要时增加部分完成。模型生成“已完成”不改变系统状态，真实返回与业务记录才是依据。

上线前演练停止与恢复：停用相关能力、撤销工具权限、恢复人工路径、确认已执行动作、处理剩余队列。回滚代码不能撤销已经发出的邮件或退款，应提前设计补救与责任。

技术深读可参阅Harness Agent 策略治理。课程中的规则必须落实到所选运行系统，不因采用某个框架而默认已经具备。

8.5 完整成本与投资评审

预算分为建设、运行与变更。建设包括诊断、数据整理、开发集成、评估与培训；运行包括模型、软件、基础设施、渠道、人工审核与异常；变更包括版本升级、新市场、接口变化和业务规则调整。已有人员投入也应记录，避免外部费用下降掩盖内部工作增加。

收益分为现金、能力与风险。现金收益有真实新增贡献与实际支出减少；能力收益表现为缩短等待、释放工时和扩大覆盖；风险收益表现为可计量损失减少或控制改善。不能把所有释放工时折算为裁员节省。

以下为教学演算：建设投入 30,000；每月运行 3,000；每月经核实新增贡献和实际支出减少合计 8,000。稳定运行时月净收益为 5,000，简单回收期为 6 个月。该演算未考虑爬坡、收益波动和资金时间价值，正式评审需补相应情景。

若前两个月未产生收益且仍有运行费，六个月项目的现金结果不同于稳定期计算。三种情景可以分别假设业务量、采用率、审核时间与故障：保守、基准、乐观。参数来自历史或试点，预测部分明确标注。

单位任务成本可按“通过验收且完成业务闭环的任务”计算。便宜模型如果导致更多返工与人工处理，整体成本可能更高；复杂多 Agent 如果不能改善结果，只会增加维护与调用。选型应比较任务结果，而非只比较 Token 单价。

评审同时写暂停与退出条件。例如关键质量达不到要求、负责人无法持续维护、依赖系统长期不可用、真实成本超过批准上限或经营收益不足。退出应保留数据、资料和人工流程，避免采购平台后失去选择。

8.6 90 天路线图与阶段验收

90 天用于组织试点与复盘，不代表所有增长问题都能在三个月解决。B2B 成交周期可能超过观察期，库存或复购可能需要更长周期。阶段目标可先验证流程与中间指标，继续追踪最终结果。

第一阶段完成后才进入后续：资料与权限未落实，先解决准备；质量不足，继续验证；运行故障未控制，暂不扩大；业务采用低，回到流程和责任诊断。日期不是跳过门槛的理由。

路线图只选择一项主要闭环，其他场景按依赖排序。外贸可以先做询盘补全与草稿；平台电商可以先做内容或广告只读诊断；DTC 可以先做限定知识客服与工单。市场与内容等相关能力按实际需要并入，不一开始同时搭建全部系统。

每周交付一项可检查的结果。资料表、可运行任务、评估、系统记录、试点报告和交接文档分别具有完成条件。业务负责人参与验收，并提供实际使用反馈。所有问题进入任务表，标明优先级与负责人。

移交包括账号与资产、知识维护、工具与流程、评估、发布、故障恢复和费用。接受方应独立完成一次知识更新、一次失败处理和一次恢复演练，才证明能力能够持续运行。提交文档本身不能证明已完成内化。

8.7 编排平台与毕业方案

n8n、Activepieces可以作为流程与系统连接候选，Dify可以作为 AI 应用构建候选。工具能力、企业特性、许可与部署条件分别确认。n8n 官方有 Sustainable Use License 说明，不能把可查看源码等同于任何用途都无限制的开源许可。许可说明

平台比较围绕输入、系统、状态、审批、异常、观测、权限、维护和总成本。无 IT 团队需要明确谁管理部署与升级；成熟 IT 团队需要检查是否与现有身份、审计和数据系统衔接。拖拽流程降低部分实现门槛，不消除业务判断与技术责任。

业务步骤清楚时使用工作流，开放式研究可以使用 Agent。需要多个 Agent 时，每个任务有目标、资料、输出与停止条件，聚合结果保留来源和状态。不要为了模拟组织图增加无实质职责的角色。

毕业方案包含经营诊断、市场与客户、首项能力、目标流程、数据、架构、人机职责、权限、评估、预算、90 天路线图和持续运营。方案中的预测与事实分开，重要输入有来源，技术选择说明为何适合当前企业。

评审可以按经营价值、流程完整、证据与数据、实施与控制、评估与运营五项评分，每项 20 分。该评分为课堂设计，不是行业认证。建议设置通过门槛，并将虚构关键事实、越权动作、缺少责任人或不可验收作为独立退回条件。

方案路演不以工具演示数量评优。一项能力如果能稳定处理真实任务、保留人工例外并记录结果，比多个无法持续使用的演示更接近企业价值。评审最后决定继续准备、限定试点、正式运行或停止，并说明依据。

三类企业的实施起点

B2B 外贸企业宜从一条询盘旅程建立闭环：收到、识别、查询资料、补问、人工确认、任务、报价版本和项目进度。最重要的准备是产品事实、工厂确认与客户归属，结果先观察需求完整、等待与报价质量，再追踪商机。

平台跨境电商宜从商品或经营任务开始：统一商品、订单、费用与库存，选择内容审校、评价归因或广告诊断。先建立可信口径再自动调整，结果同时观察利润、质量、库存和人工时间。

DTC 品牌宜从客户购买或服务旅程开始：页面、配送、支付、订单、知识、客服与工单形成连续体验。先限定商品与市场，结果看正确购买、解决问题、重复咨询与贡献，再扩展到复购和更多语言。

三类企业可以复用知识、接口与评估机制，业务规则不能直接互换。B2B 的技术评估不能缩成购物车转化，平台订单归因不能替代 DTC 全渠道贡献，消费商品的售后模板也不能直接处理工业项目验收。

本章实战与最终验收

将前七章成果汇为一份毕业方案。保留真实事实和来源，删除无依据的效果承诺。每个动作指定负责人，每项指标明确公式与基线，每个系统说明权限与接口，每个阶段写完成证据。

评审追问一次完整任务：何时触发、怎样获取资料、谁判断、系统做什么、失败怎样处理、如何确认结果、谁持续维护。任何一步无法说明，都说明方案尚有缺口，应补齐后再批准相应投入。

本章交付物：团队职责、公共资产、权限与工具表、评估集、成本模型、90 天路线图、运行与移交清单及毕业方案。模板见实战工具包。