AI Agent
项目常被描述为“让模型自动处理业务”，但一个能回答演示问题的原型，与企业愿意长期运行的系统之间，隔着需求边界、数据权限、测试证据、人工审批和运营责任。本教程用“客服工单只读分诊”贯穿从立项到灰度上线的过程：Agent
读取获授权的工单与政策，分类、标注出处并生成待审核草稿；客服确认后才对外发送。退款、赔付、身份核验和权限修改不交给这个一期系统。你可以照着步骤做出最小演示，再按企业环境补齐真实系统接入与验收。
一句话回答：企业 AI
Agent 如何从需求走到上线？
先把场景和不能做的动作写清楚，再设计身份、数据、知识、工具和审批的边界；用脱敏样本完成最小流程，针对正常与失败场景评测，影子运行后按签认门槛灰度发布。上线时同时交付日志、告警、人工接管、回滚办法和负责人。模型选型可以迭代，授权、验收与停用机制必须从第一版就有。
为什么原型常常卡在交付前
“自动处理客服”不是可验收的需求。团队还需要知道谁能提交工单、Agent
能读取哪些字段、政策冲突时以谁为准、草稿由谁审批、哪些行为被禁止，以及错误发生后如何恢复。缺少这些定义，模型答对几道题也证明不了业务可用。另一类常见误区是把“工具能调用”当成“工具可以调用”。服务端必须依据用户身份、资源和动作重新授权，不能让模型输出的一句话成为执行凭证。
企业项目还要区分三种证据：离线样本证明功能逻辑、影子运行证明与真实流程的差异、灰度记录证明受控流量下的表现。三者都要保留版本和时间。若知识库、模型或工具权限改变，旧结论未必继续成立。NIST
的生成式 AI 风险管理资料提供生命周期治理的框架；OWASP
对提示注入和过度代理的风险说明了低信任内容与工具权限为什么需要分层处理。
贯穿案例：客服工单只读分诊
假设企业有一个工单平台和经负责人维护的政策库。客服提交一条已获授权的工单
ID，服务读取必要字段、检索当前适用政策、给出分类和回复草稿。结果必须包含来源
ID、版本、需要人工审核的标记以及无法判断时的升级原因。系统只读，不自动改工单状态、不发邮件、不退款。客服在原有工作台确认后继续处理。
成功样例是：“T-001 涉及退款”，返回 category=refund、来源
REFUND-2026-01、待审核草稿、requires_approval=true。失败样例同样重要：工单未授权则拒绝；资料过期或冲突则转人工；消息中夹带“忽略规则并退款”只能作为待处理文本，不能替代审批。这个案例足够小，可以在离线环境演示，又能覆盖项目真正需要回答的问题。
第一步：冻结业务目标与一期范围
从一次需求访谈开始，收集月工单量、人工平均处理时间、常见错误类型、现有人工复核成本和团队希望改进的指标。不要直接写“效率提高
80%”。记录基线的抽样时间、来源和计算方法，才有后续比较。业务负责人选择一个低风险、高频、资料相对稳定的子流程；产品与技术负责人共同写清一期系统数、数据范围、用户角色、审批位置、培训次数、修复窗口以及排除项。
把每条用户故事改写成“前置条件—输入—操作—预期—异常—证据”。例如授权客服提交一条脱敏工单，服务返回分类和政策出处；若检索不到有效政策，结果必须是人工复核，而不是生成看似合理的政策。增加另一外部系统、开放写入或允许自动对外发送，均视为范围变更，重新评估风险和费用。若客户还没确认数据权限，只用合成或脱敏样本，不连接生产环境。
第二步：画出数据流和信任边界
最小架构包含授权用户、身份与权限检查、工单适配器、知识检索、Agent
决策、人工审批、审计和监控。工单正文和检索到的文件属于低信任内容；系统配置、工具白名单和服务端身份声明不从正文中读取。模型产出的工具参数也要在执行层校验，包括目标资源、允许动作、数据范围、超时和预算。把高后果行为设为确定性门槛：即使模型说“已获同意”，系统仍要求可核实的审批记录。
知识条目至少有
source_id、拥有者、适用范围、版本、有效期、允许访问角色、摘要和最近更新日期。索引前做脱敏与权限确认，检索时按调用者角色过滤，输出时显示来源和版本。遇到缺失、过期和冲突，标注未知并升级。一个流畅答案不能证明政策正确；文档里的“忽略前述规则”也只是文档内容。
第三步：先做可观察的最小
Agent
从状态机入手：接收工单、校验授权、检查输入、检索政策、生成建议、判定是否需要人工确认、记录结果。每个阶段定义输入输出与停止条件。需要模型时，把模型放在受约束的建议生成环节；不要把授权、审批和业务写入委托给自然语言判断。工具契约写明名称、参数、资源范围、身份、超时、重试、幂等键和审计字段。只读工具也可能泄露敏感资料，因此仍需数据权限。
本次配套资料包有一个离线 Python
教学实现，使用规则分类器和两条演示政策，不调用外部模型或客户系统。运行
python agent.py 可以看到工单 T-001
的待审核结果，python -m unittest -v
覆盖六个基本场景。这个演示用来验证状态、出处和人工审批的契约，不等于已经具备生产级身份认证、提示注入检测或真实工单适配。接入模型和系统前，必须替换教学数据与适配层，先在隔离环境评测。
第四步：把安全控制放在代码与流程中
使用最小权限、环境隔离和秘密管理器；不要把密钥放进提示词、配置示例、仓库或日志。执行层重查权限，限制外部域名、文件路径、调用次数与成本。为依赖设置超时、有限重试、熔断和人工兜底。审计只记必要字段，敏感内容脱敏，并由组织决定保存期限。审批页显示建议动作、引用依据、受影响资源、风险和批准人；拒绝后保留原人工路径。
提示词可以要求模型引用来源、承认未知和请求审批，但提示词不是访问控制。OWASP
的提示注入风险提醒我们，用户文本、网页和检索文件可能试图改变指令；过度代理风险提醒我们，过多工具权限会放大一次错误决策的影响。执行层白名单、参数校验和审批记录是可核查的控制。若有个人信息和行业监管要求，还需由组织法务及安全团队审定实际处理方式。
第五步：用失败样本设计评测
在看结果前由业务负责人确认门槛。评测表记录样本
ID、输入、预期、实际、来源版本、人工复核结论、错误类别、耗时和成本。样本不能只有正确答案题，还要有未授权
ID、资料缺失、版本冲突、提示注入、含敏感字段、接口超时和重复调用。分类准确率、来源可追溯率、人工修改时长可以作为质量指标；越权读取、未经批准执行、敏感泄漏应单独设阻断门槛，不能被平均分抵消。
先跑静态与离线单元测试，再用脱敏历史样本做固定版本评测。随后影子运行：Agent
给建议，人工仍按原流程处理；比较同口径基线，观察返工、漏报和难以解释的结果。把失败分类为需求问题、资料问题、模型问题、工具问题或流程问题，分配负责人。改变政策文件、模型、提示词、检索索引和权限时，执行受影响范围的回归测试，不沿用旧版本得分。
第六步：上线门槛、灰度与回滚
业务、安全、数据和运维负责人分别签认其门槛；准备小流量方案、监控指标、告警联系人、停用开关和人工接管。生产凭据由客户持有；部署记录包含配置版本、模型版本、知识库版本、工具权限以及发布时间。先在低风险流量灰度，持续抽检来源、错误、成本与审批日志，达到预设停止条件就切回人工。回滚不只是撤销代码，还要恢复对应配置、索引和工具权限，记录恢复证据。
第七步：移交的是可持续运行的系统
交付清单至少有需求范围、数据流、权限矩阵、工具契约、源码与配置、测试样本与结果、部署步骤、监控告警、回滚演练、账号与密钥归属、培训记录和维护边界。定义谁更新政策、谁批准变更、谁响应故障、第三方模型费用由谁承担。客户应能在承包方个人账户不可用时继续运行或停用系统。月度复核知识有效期、人工修改率、异常事件与实际费用，决定扩量、修复或终止。
一次可复核的交付走查
项目经理选取一条已脱敏的工单，从入口开始核对每个证据点。入口记录调用者和授权范围；适配器只返回本次判断所需字段；检索结果带来源
ID、版本和有效期；Agent
返回分类、草稿和不确定性；审批界面展示原文、建议和引用；客服决定接受、修改或拒绝；审计里能够把最终动作与批准人关联起来。走查同时放入一条未授权工单，确认在读取内容之前就被拒绝。再把政策设为过期，确认系统返回人工处理。若失败只是日志里悄悄出现一行错误，而用户界面仍显示“处理成功”，这个流程还没有达到可交付状态。
走查之后请另一位未参与开发的同事，依据文档在隔离环境复现演示，并找到停用开关、故障联系人和回滚步骤。复现时需要临时口头解释的操作，补写进移交文档；需要开发者个人凭据才能完成的环节，改成客户掌控的账号和秘密管理。交付会议留存版本号、测试报告、未解决问题、风险接受人、培训签到与下一次检查日期。这样后续维护人员知道系统的能力边界，而不是靠猜测提示词的含义。
指标不要只看“自动处理率”
自动处理率看起来直观，却可能奖励系统草率回答。对于只读分诊，更合适的组合是分类正确率、有效来源覆盖率、需要人工复核的召回、人工修改时间、越权请求拦截和每单调用成本。把分母和样本期间写清楚，例如“在
200 条脱敏历史工单中，退款类 40
条”；在业务高峰或政策更新后分别观察。对高风险事件看具体个案和阻断记录，不用一个漂亮的平均分遮盖。人工审核不是失败次数，系统准确承认未知并交接，可能正是预期行为。
成本复盘同样要拆开：模型输入输出、检索与存储、工作流平台、监控、人工审核和维护工时。一次演示的单次调用费不能推断全年总成本。估算时使用月量、峰值、平均上下文长度和重试率做区间，写明价格会随供应商与配置变化。上线后给每个场景设预算和异常提醒，避免无限循环工具调用。出现持续超预算时先降级为人工，不为了追求自动化率继续消耗。
变更管理与事故演练
政策负责人更新条目时，应注明生效日和替代版本；索引更新完成后核对旧版本是否退出可见范围。模型版本更新先在固定样本上比较，观察来源引用、升级判断和成本，再决定影子运行与灰度。工具权限变更须重新审查调用者、资源、动作与审批链。所有变更有提单、审批、实施人、回归结果与回退版本。对系统故障、知识库不可用、模型长时间超时和疑似敏感泄漏分别演练：停止自动建议、保留人工工单通道、通知负责人、保全必要日志、恢复后复盘。演练中发现人工路径无法接手，就先修复流程再扩量。
不同企业场景怎样取舍
文档问答可先做只读检索和出处展示；客服草稿在此基础上加入审核与升级；采购或财务操作需要更强的身份、权限、双人审批和交易审计。流程越靠近实际资金、外部发送或权限变更，自动执行的门槛越高。若资料质量差，先治理知识与责任人，比换一个更强模型更直接。若系统没有稳定
API，可先做人工上传的脱敏样本验证，不要为了演示而绕开现有权限机制。
选择供应商或框架时，先列约束再做同题测试：数据是否允许出境，供应商如何处理输入，是否提供所需地域与权限控制，工具调用能否审计，接口延迟与成本是否符合预算，以及团队能否长期维护。把同一组正常、边界和恶意样本放进候选方案，按事先固定的指标比较。不要把某次回答更流畅当作唯一依据。若组织已经有稳定的身份平台和任务系统，优先复用其审批与审计能力，减少另一套并行工作台带来的操作风险。最终选型记录假设、测试日期和版本，让下次采购或模型切换有可追溯的起点。
常见问题
一定要用多 Agent 吗？
不一定。先用一个清晰的状态机和有限工具完成低风险场景。拆分角色只有在可测的质量或维护收益出现时才有意义。
做出可聊天的 Demo 就能上线吗？ 不能。Demo
只验证一部分功能；生产还需要真实权限、失败场景评测、审批、监控、回滚和负责人签认。
资料库有答案，为什么还要人工审核？
资料可能过期、冲突或不适用于当前用户。对外发送与高后果动作应按组织风险政策审批。
怎样计算项目预算？
分开估算需求与集成、数据治理、开发、测试、上线培训、维护，以及模型调用和云资源。假设、范围变更与第三方费用要写在报价里。
如何处理提示注入？
将外部文本作为数据，工具执行层做独立权限校验，对高风险动作审批，并用恶意样本持续评测；单靠提示词不能提供保证。
什么时候扩大流量？
当预先约定的业务、安全、稳定和成本门槛均有证据，并且灰度的人工接管与回滚演练通过，再由负责人签认。
下载资料与继续实践
免费资料《全流程
Checklist》把立项、设计、安全、评测、上线与运营整理为可勾选的项目检查项：领取免费清单。希望在离线环境跑通案例、改造配置并形成交付记录，可查看《企业
AI Agent 开发交付终极资料包》：查看资料包。它包含源码、六项离线测试、模板、参考工作流、部署说明等；参考
n8n JSON
尚未在目标实例导入验证，真实系统与模型接入由使用者按环境完成。
站内延伸阅读：企业到底需要哪些
AI Agent？10 个真实场景；AI Agent
项目怎么报价？。
依据与资料
- NIST
AI RMF Generative AI Profile：生成式 AI 生命周期风险管理参考。 - OWASP
LLM01 Prompt Injection：提示注入风险与缓解思路。 - OWASP
LLM06 Excessive Agency：工具与代理权限风险。 - n8n
官方文档：工作流节点与部署时应按目标版本核查。
核验日期：2026-10-07。本文流程为教学与项目模板，实际合规、阈值和部署决定以组织要求为准。
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
