AI 智能体上线前如何定义生产级项目范围

生产级 AI Agent 的范围应是一份运营契约，而不是功能清单。它必须把一个业务结果和明确负责人，与 Agent 的输入、工具、权限、输出、人工控制、验收场景、证据、交付资产和运行假设连接起来。缺少任何一环，两家能力相当的 Builder 就可能在同一需求下报价两个完全不同的系统。

范围定义不是提前预测全部技术细节，而是明确什么事实成立时，客户会接受、运行并继续改进这个 Agent。好的规格为工程判断保留空间，同时让责任和证据没有歧义。

从结果与负责人开始

最强的范围首先描述真实工作流的变化：什么事件触发、谁使用、当前如何处理、期望产生什么结果、为什么重要。“做一个研究 Agent”只是类别；“对每家已批准公司生成带来源引用的风险简报，由分析师在周会前复核”才是运营边界。

指定一位接受业务结果的运营负责人。此人负责处理例外、权威来源、复核阈值和推广取舍。技术负责人可以另外接受代码、安全和部署资产。如果需要多人审批，就分别写明每个人拥有哪些决定，而不是笼统地写“由项目组确认”。

用已有证据建立基线，例如单次耗时、吞吐、积压、返工、错误暴露、响应时间或成本。随后选择一个首要结果和少量护栏，例如在保持评审接受与来源可追溯的情况下缩短材料准备时间。目标数值可以在发现阶段校准，但测量方式不能一直模糊。

结果模块至少回答六个问题

• 什么事件启动流程？
• 谁使用或复核结果？
• 哪个决策或任务发生改变？
• 当前基线是什么？
• 哪个首要指标代表价值？
• 谁最终接受结果？

这一模块可以防止项目向“看起来更智能但并未改变运营”的能力漂移。

把输入、工具和权限拆成三份契约

输入规定 Agent 能知道什么，工具规定它能做什么，权限规定它在特定身份和情境下允许知道或做什么。用一句“集成企业系统”把三者混在一起，会隐藏最重要的架构、风险和成本。

输入：明确权威、敏感度和时效

列出每类输入：用户请求、业务记录、文档、消息、事件、政策、历史决策和外部数据。逐项说明权威来源、负责人、格式、数量、敏感级别、更新频率、保留规则和已知质量问题。

还要说明来源冲突或上下文缺失时如何处理。检索不只是连接器问题，规格应规定 Agent 是否必须引用、是否只使用批准集合、是否拒绝过期记录，以及何时向用户补充提问或转交人工。

尽早准备代表性样例。十个经过挑选的正常、失败和异常案例，往往比一份泛化数据目录更能暴露问题，也可以直接成为评估集的起点。

工具：用业务动作描述副作用

按业务动作列工具，而不只列 API 名称。“创建工单草稿”“读取账户余额”“提交退款审批”比“连接 CRM 和财务接口”更清晰。每个动作应记录输入输出、预期错误、幂等、限流、延迟和审计事件。

严格区分读取、建议和执行。Agent 可以读取记录，可以提出修改等待人批准，也可以直接写入。三种模式的风险和验收完全不同。首个版本应使用能够证明价值的最低权限，再依据证据扩展。

权限：让最小权限原则可测试

明确 Agent 代表哪个用户或服务身份操作，授权如何校验，以及权限是否随租户、团队、数据类别、地区或流程状态变化。验收场景必须包含拒绝访问。正确系统不只是成功调用，还应在越权时安全拒绝并留下原因记录。

密钥、令牌和凭证需要负责人、存储、轮换和撤销规则。交付包不应包含生产密钥，而应包含配置说明和权限边界经过验证的证据。

把输出、人工复核与约束一起定义

输出只有放到“谁复核、什么约束”中才有意义。自然语言回答、结构化记录、操作建议和已经执行的交易，需要完全不同的证据和责任。

定义输出契约

写清格式、必填字段、引用、置信或不确定性表达、目标位置和时间要求。如果下游软件读取，应定义结构和校验失败方式；如果人类使用，应定义可读性、来源展示和编辑方式。

还要明确 Agent 禁止生成或推断的内容。例如可以汇总批准政策，但不能自行创造例外；可以建议账户操作，但不得绕过指定审批人直接执行。

把人工复核放在明确决策点

“有人参与”并不是控制。必须说明谁在什么时间看到哪些信息、能做什么决定、如何记录修改、拒绝后如何处理、无人响应时如何升级。

复核行为可以成为评估证据：接受、编辑、拒绝原因、升级和撤销都应记录。但不能只优化接受率，因为复核者可能为了清空队列而通过低价值输出。应把复核指标与正确性和业务结果相连。

把非功能约束写进范围

安全、隐私、数据驻留、保留、可解释性、可用性、延迟、吞吐、成本、无障碍和支持环境都影响架构。暂时无法给出精确数字时，可以先写范围和决策阈值，但必须在验收前转成可测量标准。

模型或云厂商限制应与业务结果限制分开。如果系统必须跨模型迁移或只能运行在指定云上，要明确写出；如果不存在这种要求，就不要因为习惯增加不必要成本。

在架构固化前写验收场景

验收场景把范围变成可验证协议。每个场景描述起始条件、输入、期望行为、禁止行为和证据。它们不一定都是自动化测试，有些需要领域、安全或人工评审；价值在于所有参与方能看到“完成”究竟意味着什么。

一、正常场景

覆盖创造主要价值的常见路径，包含代表性数量和数据差异。预期结果必须可观察，不能只写“正确运行”。

二、边界与模糊场景

覆盖来源冲突、指令不清、特殊格式、记录不完整和接近范围边界的请求，并规定 Agent 应补充提问、降级输出还是交给人工。

三、权限与政策场景

测试有权与无权用户、敏感字段、禁止动作，以及通过文档内容覆盖系统指令的尝试。预期结果应包含拒绝、记录和必要的升级。

四、依赖与故障场景

模拟工具不可用、超时、部分写入、重复事件、模型错误和过期数据，明确重试、回滚或补偿、用户提示以及故障证据。

五、质量与运营场景

在约定数据集或生产样本上测量任务成功、引用、复核、延迟、成本和可观测性，并指定谁裁决边界结果、证据保存在哪里。

每个场景都要指定证据形式，例如输出文件、日志、截图、链路记录、评估报告、评审签字或部署端点。没有证据要求，验收很容易退化为主观演示。

定义 Agent Package 与交接

生产交付不只是把代码部署到一个环境。客户需要一套可检查、可运行、可修改的 Agent Package，范围通常包括：

• 源代码和版本元数据；
• Agent 指令与配置；
• Skills、工具、连接器和适配器；
• 基础设施与部署配置；
• 评估数据、场景、方法和结果；
• 安全和权限设计；
• 监控、告警和成本控制；
• 日常运行与故障手册；
• 架构决策与已知限制；
• 管理员、运营者和用户文档；
• 交接会议与责任矩阵。

同时明确仓库、使用权、环境边界、支持版本和验收接收人。如果供应商提供持续服务而不交源代码，就要另行定义数据处理、服务水平、退出支持和可迁移性。

交接计划必须回答谁能部署、谁能修改行为、谁批准发布、谁处理故障、谁支付第三方用量。无法回答这些问题，系统就还不是完整的运营产品。

把假设与承诺分开

假设是计划依赖但尚未验证的事实，例如某 API 支持所需动作、样本能代表生产、安全团队会批准某种方案、领域专家能在两天内反馈。每项假设应有负责人、验证方法、期限和失败后影响。

依赖则是交付团队之外的明确承诺，例如凭证、沙箱、法务审查或专家时间，必须进入计划。隐藏的客户依赖，是很多工程延期看起来像供应商问题的根源。

开放问题不必全部阻断启动。可分为报价前必须解决、构建前必须解决、以及可以在边界清晰的发现阶段处理三类。这样既保持速度，也不假装不确定性已经消失。

用最薄生产切片控制范围

首个版本应穿过完整运营路径，但主动限制宽度。可以限制用户、地区、文档、工具、动作、数据类别或异常类型，同时保留生产控制、评估、监控和交接标准。

例如客服 Agent 首期只处理一种争议类型，只读客户数据，只生成草稿，并由指定人员复核；但它仍应具备认证、审计、引用、评估、监控和回退。这种设计能在不授予过宽权限时暴露真实生产约束。

扩展条件也要提前定义。新增动作或用户应依据实测表现和运营准备，而不是日历压力。每次扩展都要同步更新权限、场景、成本假设和支持责任。

发出报价请求前的十二项检查

1. 一个工作流、主要结果、基线和负责人；
2. 用户、触发、当前流程和预期改变；
3. 范围内及明确排除的动作；
4. 输入来源、权威性、敏感度和可用性；
5. 工具动作、副作用和失败行为；
6. 身份和权限边界；
7. 输出格式、目的地和禁止行为；
8. 人工复核与升级决策；
9. 非功能和运营约束；
10. 验收场景与证据；
11. Agent Package 内容和交接责任；
12. 假设、依赖、开放问题和变更机制。

这份清单不要求客户自己完成架构设计。它提供足够的共同基础，让合格 Builder 能够提出架构、里程碑、证据和报价，而不是通过猜测填补关键空白。

把范围变成清晰商业边界

最终规格应把付费定义工作，与实施、第三方成本和持续运营分开，明确本次成果包含什么、哪些内容需要后续合同。这样即使发现改变了架构或工作量，客户与 Builder 也能基于同一事实重新决策。

WWW Agents 提供 599 美元的专家评审 Agent Build Specification。你可以先提交私密 Build Request进行资格判断，提交本身不收费；通过资格判断并决定继续后才需要付款。付费成果是规格文件，不包括实施、后续 Builder 合作，也不承诺规格费用抵扣未来构建。