做 Agent 项目评审最怕的就是“会上热热闹闹散会各干各的”。我这两年被拉进过好几轮 Agent 项目的评审从产品、运营、开发、算法到 QA 的立场都站过最大的感受是Agent 项目跟传统业务需求完全不是一个评审节奏。以前需求评审只要把页面流程和接口逻辑对着讲一遍就够了Agent 一来需求本身是模糊的、模型行为是概率性的、验收边界是漂移的稍微没对齐开发做出来一版产品说不是想要的QA 说没法验收算法说模型能力就到这最后全变成互相甩锅。这篇摘要把我们团队实际跑通的四段评审链路——需求预评审、需求评审、技术方案评审、TC 评审——完整梳理一遍。每一段谁参加、聊什么、必须产出什么、怎么算通过我都按实操经验写清楚。适合正在做 Agent 项目或者正准备立项的产品、开发、算法、QA 同学参考也算我踩了一整年坑之后的完整复盘。1. 评审链路为什么拆成四段传统需求评审不适用于 Agent很多人觉得评审链路拆成四段太啰嗦一个需求评审会开完不就行了真不是。传统业务系统是确定性系统用户点哪个按钮、调哪个接口、走哪条分支都是可以提前穷举的评审时对着原型图和接口文档过一遍边界自然就清晰了。Agent 不一样它面对的是“用户输入不可穷举、模型输出不可穷举”的开放场景你没法在评审会上把用户可能说的每句话都列出来自然也没法用一个需求文档把行为边界完全钉死。拿一个最简单的“退换货客服 Agent”举例。传统客服系统只需要定义“用户选退换货 - 填单 - 上传凭证 - 审核”分支有限评审时一条条走完就结束了。换成 Agent 之后用户可能直接说“我衣服买大了想换小一码但吊牌拆了还能换吗”也可能说“你们客服是不是机器人我要投诉”还可能说“我朋友让我帮她问一下她的订单”。这些一句话就把意图、情绪、多轮上下文全搅在一起的输入如果评审时没有提前定好边界开发就只能靠猜算法也只能拿通用模型硬怼最后产品体验全靠运气。所以我把评审的思路从“一次评审定终身”改成“分段收敛不确定性”。每一段评审都把一部分未知问题提前消灭掉让下一段的参与者带着更明确的输入进场。1.1 四段评审分别解决什么问题直接放一张我内部常用的分工表后面所有内容都围绕这张表展开评审阶段核心目标主要参与角色关键产出通过标准需求预评审判断值不值得做、问题是否真实存在产品、运营、算法负责人用户目标图谱、能力边界声明、合规自检表能说清目标用户、核心场景和红线需求评审明确做什么、不做什么产品、运营、开发、算法、QA需求条目化模板、成功信号、不做清单每个条目有可观测的验收信号技术方案评审确认能不能落地、用什么方案落地开发、算法、QA、运维技术设计文档、接口协议、监控方案关键链路、失败降级、成本核算有结论TC 评审上线前安全评估和技术债评估技术负责人、开发、算法、QA、运维TC 检查清单、风险登记表、回滚方案可用性指标、风险项、责任人、时限齐备四段评审之间的关系是层层递进的预评审把靶子立起来需求评审把框子画出来技术方案评审把路子铺出来TC 评审最后验货放行。任何一段没过都不建议硬着头皮往下走否则后面返工成本会成倍放大。1.2 各角色在评审链路里的关注点差异同一个 Agent 项目产品、运营、开发、算法、QA 看到的东西完全不同。产品关注用户目标是否达成运营关注话术怎么给、转化怎么跟开发关注模块能不能拆、接口能不能扛算法关注模型选型是否匹配、评测集怎么建QA 关注验收路径和回归策略。如果评审会只是把所有人拉一起念 PPT这些视角差异根本暴露不出来。我见过太多评审翻车现场产品说“用户要的就是一个能直接解决售后问题的智能助手”开发听到的是“又一个需要处理无限种输入的前端”算法听到的是“不知道要拿什么模型去 finetune”QA 听到的是“完全没有确定性输出可以断言”。每个人都在同一句话里听出了不同的需求散会之后自然各干各的。所以后来我们强制要求每一段评审都要有明确的一页纸结论页上面写清“这一段结束之后下一段的输入是什么、约束是什么、开放问题还有哪些”。没有这个动作评审会就是无效会议。2. 需求预评审和需求评审怎么做把模糊想法变成可讨论的需求四段评审里需求预评审和需求评审挨得最近也最容易被人合并成一场会。我强烈建议别合并因为预评审聊的是“要不要做”需求评审聊的是“具体做什么”这两个问题混在一起结果就是会越开越长结论越来越虚。2.1 需求预评审怎么开这是项目踩坑最多的一关预评审的设计初衷是“花最小的成本判断方向对不对”。这个阶段不聊技术细节也不聊排期重点就聊三件事。第一件事是用户目标图谱。把产品侧收集到的真实用户语料拿出来按高频场景掰开揉碎列出用户在什么情境下会产生什么目标、会用什么方式表达。比如做一个“企业差旅报销 Agent”用户目标不止是“报销”还包括“想知道这个发票能不能报”“催财务快点审批”“帮同事问报销进度”。这些隐含目标如果不在图谱里Agent 就会在交互中频繁“听不懂”。第二件事是 Agent 能力边界声明。这一个动作能挡掉后面至少一半的扯皮。边界声明里要写清楚这个 Agent 到底能用哪些工具、能读取哪些数据、绝对不能碰哪些操作、哪些话术必须强制转人工。边界不是越宽越好而是越清晰越好。宁可第一版能力窄一点也不能让 Agent 在自己的权限范围内乱跑。第三件事是安全与合规自检。涉及个人信息、支付、医疗、法律建议这些敏感领域必须在预评审阶段就拉出红线明确“这类问题一律不回答或转人工”。很多 Agent 事故不是出在模型能力上而是出在“没有提前声明不能做什么”上。预评审的模板我是这样设计的直接复用即可字段填写说明项目代号方便评审记录追踪目标用户与场景用户画像、高频场景、使用入口用户目标图谱显性目标 隐性目标至少 5 条能力边界声明允许做什么、拒绝做什么、转人工条件合规自检结果涉及哪些敏感数据、如何拦截/脱敏不做清单首版明确不做的内容预评审结论通过 / 修改后复审 / 不通过这阶段最容易被忽略的是“不做清单”。所有 Agent 项目都会面临用户乱问问题不提前写清楚哪些不做开发就只能把所有能力都暴露给模型安全隐患和成本风险全上来了。2.2 需求评审把“想法”翻译成可验收需求预评审通过之后需求评审要解决的是“具体做成什么样”。我强烈建议不要写大段自然语言 PRD而是用需求条目化的模板一条一条把需求钉死。每条需求包含以下字段场景编号方便建立对应评测集和回归用例用户目标用户想通过这句话达到什么目的触发条件什么样的输入会进入这个场景Agent 行为上限允许做到哪一步不允许做什么明确的行为禁区依赖数据与权限需要读哪些数据、调哪些工具成功信号可观测、可量化的验收标准降级路径模型不可用或识别失败时怎么办举个例子“差旅报销 Agent”的需求条目可以这样写场景编号EXP-001 用户目标用户询问某笔订单能否报销 触发条件用户输入包含“这个能不能报销”“这票能报吗”等疑似报销资格询问 Agent 行为上限基于报销规则库给出明确结论并解释依据 不允许做什么不允许擅自修改报销单状态不允许给出与规则库冲突的建议 依赖数据报销规则库、订单数据、用户权限 成功信号在评测集上报销资格判断准确率 90%回答包含规则依据的比例 80% 降级路径无法匹配规则时统一回复“需要人工核实”并创建工单需求条目里的成功信号特别关键。很多团队写的是“回答要友好”“用户要满意”这种不可观测的信号等于没有。可观测信号可以是准确率、转人工率、无效调用率、响应时长这类硬指标。有了这些信号后面 QA 才知道怎么设计验收用例算法才知道怎么搭评测集。2.3 开发侧同步准备评审时就要想的架构问题需求评审进行的同时开发不能只看热闹需要同步确认一些架构层面的前置问题。Agent 项目的工程架构和传统后端最大的区别在于多了一个模型运行时所有行为都从“确定的接口调用”变成了“模型推理 工具调用 状态流转”。开发侧至少要在需求评审阶段确认四件事。第一总体规划里调度编排层、模型接入层、工具执行层、记忆状态层、安全审计层分别由谁负责不能把所有东西都堆在一个 service 里。第二全链路 trace 方案必须提前定Agent 每次的输入输出、模型返回、工具调用结果、token 消耗都要有日志链路否则出了线上问题只能靠猜。第三“扛并发”方案要有雏形Agent 的并发瓶颈不在服务本身而在 LLM 接口、上下文窗口、工具调用串行化这几个点评审时要明确模型网关的限流策略、缓存策略、降级策略。第四工具型 Agent 的调试环境很多 Agent 项目死在联调阶段——代码本地调通了一接真实工具就频繁超时或权限不足最好提前规划沙盒环境或者模拟工具。3. 技术方案评审和 TC 评审全流程实操预评审和需求评审解决的是“做什么”的问题技术方案评审解决的是“怎么做”的问题TC 评审解决的是“能不能安全上线”的问题。这两段评审是最容易流于形式的因为参与者容易陷入细节忘了自己要拍板的到底是什么。3.1 技术方案评审写出一份能落地的技术设计文档技术方案评审的核心输入是技术设计文档。我见过的低质量文档只有架构图和几个接口定义完全没法评审。一份能过审的技术设计文档至少要包含以下章节背景与范围本期做哪些场景、不做哪些场景总体架构与关键链路模块划分、主流程描述、关键交互链路模块设计每个模块的职责、输入输出、异常处理数据模型与存储会话数据、记忆数据、日志数据怎么存接口与工具协议Agent 要调用的每个工具的参数、鉴权、超时、限流错误处理与降级模型超时、返回空、工具失败、上下文溢出时怎么办安全与权限最小权限原则、敏感操作拦截、注入攻击防护监控与可观测性指标、日志、trace、告警上线节奏与回滚方案灰度方式、回滚条件、责任人评审时主流程建议用文字加列表方式描述清楚例如用户输入 → 意图识别 → 场景路由 → 工具选择 → 上下文组装 → 模型生成 → 结果校验 → 降级或输出。要把每一步的“如果失败怎么办”写在旁边。比如“工具选择失败 - 重新匹配一次 - 仍未匹配 - 转人工兜底”。这条链路能讲清楚方案基本就立住了一半。评审会上我发现最容易被忽略的是错误处理。好多方案把主流程做得漂漂亮亮一问到“模型返回空结果怎么办”“工具超时 5 秒怎么办”“上下文太长被截断怎么办”就开始支支吾吾。Agent 项目里这些异常不是小概率事件而是日常事件。模型推理天然带不确定性网络和插件也随时可能出问题错误处理不写清楚上线就是赌运气。3.2 算法方案与评测设计模型选型不是选最大那个就行技术方案评审里算法侧的工作最容易被简化成“选一个大模型”。真正的算法方案要回答四个问题用哪个模型、提示词怎么管理、评测集怎么建、什么指标算通过。模型选型不能只看公开榜单要看任务本身的匹配度。评估维度至少包括准确率、延迟、成本、上下文长度、工具调用稳定性。我一般会做一张评分表把候选模型在典型场景跑一遍再评分避免听别人说“效果很好”就直接拍板。工具调用稳定性尤其重要很多 Agent 项目效果崩坏不是模型笨而是工具调用格式不稳定时不时给你多传一个参数或少传一个字段。提示词管理建议按环境管理不要写死在代码里。每次提示词改动都要版本化并且必须跑评测集回归确认改动没有破坏已通过的场景。很多团队把提示词当配置改完就上线结果某个场景悄悄崩了用户反馈了才知道。评测集是算法方案里最能体现工程能力的地方。至少要覆盖每个 P0 场景 20 条以上语料包括正例、反例、边界输入、攻击性输入。评测维度建议包含四类内容正确率、错误兜底率、无效工具调用率、单次会话 token 消耗。没有评测集的 Agent 项目算法优化就是凭感觉评审时我一般会直接追问评测集在哪没有就不给过。还有一个小点是基础算法能力的沉淀。Agent 的工具调用背后经常依赖搜索、匹配、剪枝、排序这类确定性算法跟模型能力是互补关系。能靠稳定算法解决的部分就不要让模型自由发挥这样既能提高稳定性也能省 token。一个典型例子是用户输入“帮我找到最近的门店”用规则解析加地理搜索比让模型直接输出门店结果要稳定得多。3.3 TC 评审怎么开检查清单和现场模拟技巧TC 评审在我们团队的定位是“上线前最后一道安全阀”。它不重复技术方案评审的细节重点看的是跨系统的稳定性、可维护性和技术债。TC 评审常见的翻车现场有三类。第一类是只有架构图没有任何指标问可用性目标、容量评估、成本估算全都没有。第二类是拿第三方模型能力当产品承诺比如评测集问题是“参考了某公开榜单排名所以效果一定好”但实际产品场景跟榜单场景差异巨大。第三类是技术债清单缺失上线前堆了一堆 TODO但没有人登记责任人。为了避免翻车我整理了一张 TC 评审检查清单每次线上会前先让项目组逐项自评可用性目标目标 QPS、响应时长 P95、可用性 SLA 是多少容量与并发模型网关限流值、工具调用并发上限、数据库连接估算成本估算单次会话平均 token 消耗、月度模型调用成本、缓存命中率目标安全边界Agent 能访问哪些数据、能操作哪些工具、是否有越权风险数据留存会话日志留存多久、是否脱敏、是否满足隐私要求观测与告警核心指标是否接入监控、异常是否有告警、trace 是否完善修复与回滚已知问题清单、每个问题的影响范围、回滚触发条件和负责人还有一个很有效的评审技巧现场模拟一个失败场景看项目组能不能答得清楚。比如问“如果模型在高峰期连续返回空结果 3 分钟你的系统怎么表现”技术负责人如果只能说“会加一个重试”基本说明方案没想透。完整回答应该是“重试一次 - 降级到小模型 - 再失败走人工话术 - 同时告警通知值班人”链路清晰责任到人。TC 评审的记录也要规范化风险登记表里每一项都必须有严重等级、影响范围、负责人、修复时限。没有闭环的风险项下次评审继续出现TC 就成了走过场。4. 评审会上一定会吵起来的五个问题以及我们踩过的坑无论评审链路定得多清楚真开起会来还是会有几类问题反复出现。我把这些问题和对应的处理方法整理出来基本可以直接拿来用。4.1 一定会吵起来的五个问题第一个问题是产品说“AI 必须保证成功”开发说“模型没法保证”。化解方式是用 P0/P1 能力矩阵。P0 场景是底线场景必须达到评测集准确率标准P1 场景是加分项达到基础可用即可。双方对着能力矩阵逐条核对而不是在会议室里抽象争论“AI 到底行不行”。第二个问题是 QA 问“Agent 行为是概率性的测试怎么测”。化解方式是允许 QA 放弃“断言输出是否相等”的思路改用行为指标加影子模式。也就是把正确性验证拆成多个维度意图识别是否对、工具调用是否对、策略是否命中、语气是否合规每个维度单独建立打分规则。第三个问题是“模型 API 成本太高谁来承担”。化解方式是单次会话预算控制给每条用户消息设定 token 上限超过就自动压缩上下文或者切换到轻量模型。再加一层缓存常见问答直接命中缓存不调用大模型。第四个问题是“要不要同时上多语言、多模态需求”。化解方式是做能力开关技术方案里把多语言、多模态拆成独立能力模块通过配置开关分阶段上线评审时只承诺当前开关打开的部分。第五个问题是 TC 发现技术债太多还能不能上。化解方式是把“分期重构、独立开关、回滚条件”作为通过 TC 的前置条件让技术债变成有计划的偿还而不是无限延期。4.2 我们踩过的典型坑第一个坑是把 Prompt 当配置文件结果线上出问题没法热修。后来 Prompt 全量走配置中心每次改动记录版本号并绑定评测集报告出问题直接回滚到上一版。第二个坑是拿公开榜单的模型成绩写进评审承诺。团队内部一度用“某模型在推理榜上排名很高”作为选型依据结果产品场景跟榜单场景差距巨大实际效果惨不忍睹。之后所有模型能力一律以自建评测集结果为准。第三个坑是忽略上下文窗口与长期记忆。多轮对话里用户经常前面说“我上笔订单”后面说“这个也一样”如果系统没有把历史信息正确组装进上下文Agent 就会失忆。后来加了会话记忆模块每次组装上下文时做关键信息提取效果立刻上了一个台阶。第四个坑是权限边界没定义清楚。Agent 能调用的工具权限一开始写得太宽差点出现越权操作后来所有工具接入必须走权限申请和审计日志默认拒绝一切未授权调用。Agent 项目的安全边界需要前置设计不能等出了问题再补。第五个坑是缺少仿真环境联调时把测试数据打到了线上工具里。后来搭了独立的 mock 工具服务线上和测试环境完全隔离类似事故没有再发生。这一条尤其适合做 IDE 插件类工具 Agent 的团队借鉴。4.3 评审后的快速验证手段评审通过不代表项目就稳了上线前的验证手段同样重要。我们常用的是四板斧。影子模式是最安全的验证方式把真实流量复制一份给新版本 Agent 跑但结果不直接触达用户用来观察行为差异。A/B 评测适合版本迭代同一批评测语料同时跑基线版和新版直接对比指标省时省力。trace 分析重点看工具调用失败率、无效调用率和异常兜底率这三个指标能快速暴露模型与工具之间的配合问题。回滚开关也要提前准备好模型输出异常或指标跌破阈值时一键切换到人工兜底话术等定位完问题再放开流量。这些验证手段产生的数据刚好可以作为下一轮评审的输入。Agent 项目本质上是个持续迭代的项目评审不是一次性关卡而是每一轮的校准点。如果非要说这套评审流程里最值钱的是什么我觉得不是流程本身而是强制把“不确定”变成“可讨论”的模板。每次开评审都对着同一套字段逐条过会开着开着结论就自然出来了。我个人现在的习惯是任何 Agent 项目立项前先花两小时填预评审模板哪怕只是内部自审也能提前挡掉一半需求。最后分享一个特别实在的操作技巧把评审通过的 Checklist 固化成一个团队模板库每次新项目直接复制旧文档改改比从零开始写快得多而且不会漏项。这套链路跑顺之后Agent 项目的评审从“疑难杂症”变成了“流水线作业”团队的效率和稳定性都会有质的变化。
做 Agent 项目评审最怕的就是“会上热热闹闹散会各干各的”。我这两年被拉进过好几轮 Agent 项目的评审从产品、运营、开发、算法到 QA 的立场都站过最大的感受是Agent 项目跟传统业务需求完全不是一个评审节奏。以前需求评审只要把页面流程和接口逻辑对着讲一遍就够了Agent 一来需求本身是模糊的、模型行为是概率性的、验收边界是漂移的稍微没对齐开发做出来一版产品说不是想要的QA 说没法验收算法说模型能力就到这最后全变成互相甩锅。这篇摘要把我们团队实际跑通的四段评审链路——需求预评审、需求评审、技术方案评审、TC 评审——完整梳理一遍。每一段谁参加、聊什么、必须产出什么、怎么算通过我都按实操经验写清楚。适合正在做 Agent 项目或者正准备立项的产品、开发、算法、QA 同学参考也算我踩了一整年坑之后的完整复盘。1. 评审链路为什么拆成四段传统需求评审不适用于 Agent很多人觉得评审链路拆成四段太啰嗦一个需求评审会开完不就行了真不是。传统业务系统是确定性系统用户点哪个按钮、调哪个接口、走哪条分支都是可以提前穷举的评审时对着原型图和接口文档过一遍边界自然就清晰了。Agent 不一样它面对的是“用户输入不可穷举、模型输出不可穷举”的开放场景你没法在评审会上把用户可能说的每句话都列出来自然也没法用一个需求文档把行为边界完全钉死。拿一个最简单的“退换货客服 Agent”举例。传统客服系统只需要定义“用户选退换货 - 填单 - 上传凭证 - 审核”分支有限评审时一条条走完就结束了。换成 Agent 之后用户可能直接说“我衣服买大了想换小一码但吊牌拆了还能换吗”也可能说“你们客服是不是机器人我要投诉”还可能说“我朋友让我帮她问一下她的订单”。这些一句话就把意图、情绪、多轮上下文全搅在一起的输入如果评审时没有提前定好边界开发就只能靠猜算法也只能拿通用模型硬怼最后产品体验全靠运气。所以我把评审的思路从“一次评审定终身”改成“分段收敛不确定性”。每一段评审都把一部分未知问题提前消灭掉让下一段的参与者带着更明确的输入进场。1.1 四段评审分别解决什么问题直接放一张我内部常用的分工表后面所有内容都围绕这张表展开评审阶段核心目标主要参与角色关键产出通过标准需求预评审判断值不值得做、问题是否真实存在产品、运营、算法负责人用户目标图谱、能力边界声明、合规自检表能说清目标用户、核心场景和红线需求评审明确做什么、不做什么产品、运营、开发、算法、QA需求条目化模板、成功信号、不做清单每个条目有可观测的验收信号技术方案评审确认能不能落地、用什么方案落地开发、算法、QA、运维技术设计文档、接口协议、监控方案关键链路、失败降级、成本核算有结论TC 评审上线前安全评估和技术债评估技术负责人、开发、算法、QA、运维TC 检查清单、风险登记表、回滚方案可用性指标、风险项、责任人、时限齐备四段评审之间的关系是层层递进的预评审把靶子立起来需求评审把框子画出来技术方案评审把路子铺出来TC 评审最后验货放行。任何一段没过都不建议硬着头皮往下走否则后面返工成本会成倍放大。1.2 各角色在评审链路里的关注点差异同一个 Agent 项目产品、运营、开发、算法、QA 看到的东西完全不同。产品关注用户目标是否达成运营关注话术怎么给、转化怎么跟开发关注模块能不能拆、接口能不能扛算法关注模型选型是否匹配、评测集怎么建QA 关注验收路径和回归策略。如果评审会只是把所有人拉一起念 PPT这些视角差异根本暴露不出来。我见过太多评审翻车现场产品说“用户要的就是一个能直接解决售后问题的智能助手”开发听到的是“又一个需要处理无限种输入的前端”算法听到的是“不知道要拿什么模型去 finetune”QA 听到的是“完全没有确定性输出可以断言”。每个人都在同一句话里听出了不同的需求散会之后自然各干各的。所以后来我们强制要求每一段评审都要有明确的一页纸结论页上面写清“这一段结束之后下一段的输入是什么、约束是什么、开放问题还有哪些”。没有这个动作评审会就是无效会议。2. 需求预评审和需求评审怎么做把模糊想法变成可讨论的需求四段评审里需求预评审和需求评审挨得最近也最容易被人合并成一场会。我强烈建议别合并因为预评审聊的是“要不要做”需求评审聊的是“具体做什么”这两个问题混在一起结果就是会越开越长结论越来越虚。2.1 需求预评审怎么开这是项目踩坑最多的一关预评审的设计初衷是“花最小的成本判断方向对不对”。这个阶段不聊技术细节也不聊排期重点就聊三件事。第一件事是用户目标图谱。把产品侧收集到的真实用户语料拿出来按高频场景掰开揉碎列出用户在什么情境下会产生什么目标、会用什么方式表达。比如做一个“企业差旅报销 Agent”用户目标不止是“报销”还包括“想知道这个发票能不能报”“催财务快点审批”“帮同事问报销进度”。这些隐含目标如果不在图谱里Agent 就会在交互中频繁“听不懂”。第二件事是 Agent 能力边界声明。这一个动作能挡掉后面至少一半的扯皮。边界声明里要写清楚这个 Agent 到底能用哪些工具、能读取哪些数据、绝对不能碰哪些操作、哪些话术必须强制转人工。边界不是越宽越好而是越清晰越好。宁可第一版能力窄一点也不能让 Agent 在自己的权限范围内乱跑。第三件事是安全与合规自检。涉及个人信息、支付、医疗、法律建议这些敏感领域必须在预评审阶段就拉出红线明确“这类问题一律不回答或转人工”。很多 Agent 事故不是出在模型能力上而是出在“没有提前声明不能做什么”上。预评审的模板我是这样设计的直接复用即可字段填写说明项目代号方便评审记录追踪目标用户与场景用户画像、高频场景、使用入口用户目标图谱显性目标 隐性目标至少 5 条能力边界声明允许做什么、拒绝做什么、转人工条件合规自检结果涉及哪些敏感数据、如何拦截/脱敏不做清单首版明确不做的内容预评审结论通过 / 修改后复审 / 不通过这阶段最容易被忽略的是“不做清单”。所有 Agent 项目都会面临用户乱问问题不提前写清楚哪些不做开发就只能把所有能力都暴露给模型安全隐患和成本风险全上来了。2.2 需求评审把“想法”翻译成可验收需求预评审通过之后需求评审要解决的是“具体做成什么样”。我强烈建议不要写大段自然语言 PRD而是用需求条目化的模板一条一条把需求钉死。每条需求包含以下字段场景编号方便建立对应评测集和回归用例用户目标用户想通过这句话达到什么目的触发条件什么样的输入会进入这个场景Agent 行为上限允许做到哪一步不允许做什么明确的行为禁区依赖数据与权限需要读哪些数据、调哪些工具成功信号可观测、可量化的验收标准降级路径模型不可用或识别失败时怎么办举个例子“差旅报销 Agent”的需求条目可以这样写场景编号EXP-001 用户目标用户询问某笔订单能否报销 触发条件用户输入包含“这个能不能报销”“这票能报吗”等疑似报销资格询问 Agent 行为上限基于报销规则库给出明确结论并解释依据 不允许做什么不允许擅自修改报销单状态不允许给出与规则库冲突的建议 依赖数据报销规则库、订单数据、用户权限 成功信号在评测集上报销资格判断准确率 90%回答包含规则依据的比例 80% 降级路径无法匹配规则时统一回复“需要人工核实”并创建工单需求条目里的成功信号特别关键。很多团队写的是“回答要友好”“用户要满意”这种不可观测的信号等于没有。可观测信号可以是准确率、转人工率、无效调用率、响应时长这类硬指标。有了这些信号后面 QA 才知道怎么设计验收用例算法才知道怎么搭评测集。2.3 开发侧同步准备评审时就要想的架构问题需求评审进行的同时开发不能只看热闹需要同步确认一些架构层面的前置问题。Agent 项目的工程架构和传统后端最大的区别在于多了一个模型运行时所有行为都从“确定的接口调用”变成了“模型推理 工具调用 状态流转”。开发侧至少要在需求评审阶段确认四件事。第一总体规划里调度编排层、模型接入层、工具执行层、记忆状态层、安全审计层分别由谁负责不能把所有东西都堆在一个 service 里。第二全链路 trace 方案必须提前定Agent 每次的输入输出、模型返回、工具调用结果、token 消耗都要有日志链路否则出了线上问题只能靠猜。第三“扛并发”方案要有雏形Agent 的并发瓶颈不在服务本身而在 LLM 接口、上下文窗口、工具调用串行化这几个点评审时要明确模型网关的限流策略、缓存策略、降级策略。第四工具型 Agent 的调试环境很多 Agent 项目死在联调阶段——代码本地调通了一接真实工具就频繁超时或权限不足最好提前规划沙盒环境或者模拟工具。3. 技术方案评审和 TC 评审全流程实操预评审和需求评审解决的是“做什么”的问题技术方案评审解决的是“怎么做”的问题TC 评审解决的是“能不能安全上线”的问题。这两段评审是最容易流于形式的因为参与者容易陷入细节忘了自己要拍板的到底是什么。3.1 技术方案评审写出一份能落地的技术设计文档技术方案评审的核心输入是技术设计文档。我见过的低质量文档只有架构图和几个接口定义完全没法评审。一份能过审的技术设计文档至少要包含以下章节背景与范围本期做哪些场景、不做哪些场景总体架构与关键链路模块划分、主流程描述、关键交互链路模块设计每个模块的职责、输入输出、异常处理数据模型与存储会话数据、记忆数据、日志数据怎么存接口与工具协议Agent 要调用的每个工具的参数、鉴权、超时、限流错误处理与降级模型超时、返回空、工具失败、上下文溢出时怎么办安全与权限最小权限原则、敏感操作拦截、注入攻击防护监控与可观测性指标、日志、trace、告警上线节奏与回滚方案灰度方式、回滚条件、责任人评审时主流程建议用文字加列表方式描述清楚例如用户输入 → 意图识别 → 场景路由 → 工具选择 → 上下文组装 → 模型生成 → 结果校验 → 降级或输出。要把每一步的“如果失败怎么办”写在旁边。比如“工具选择失败 - 重新匹配一次 - 仍未匹配 - 转人工兜底”。这条链路能讲清楚方案基本就立住了一半。评审会上我发现最容易被忽略的是错误处理。好多方案把主流程做得漂漂亮亮一问到“模型返回空结果怎么办”“工具超时 5 秒怎么办”“上下文太长被截断怎么办”就开始支支吾吾。Agent 项目里这些异常不是小概率事件而是日常事件。模型推理天然带不确定性网络和插件也随时可能出问题错误处理不写清楚上线就是赌运气。3.2 算法方案与评测设计模型选型不是选最大那个就行技术方案评审里算法侧的工作最容易被简化成“选一个大模型”。真正的算法方案要回答四个问题用哪个模型、提示词怎么管理、评测集怎么建、什么指标算通过。模型选型不能只看公开榜单要看任务本身的匹配度。评估维度至少包括准确率、延迟、成本、上下文长度、工具调用稳定性。我一般会做一张评分表把候选模型在典型场景跑一遍再评分避免听别人说“效果很好”就直接拍板。工具调用稳定性尤其重要很多 Agent 项目效果崩坏不是模型笨而是工具调用格式不稳定时不时给你多传一个参数或少传一个字段。提示词管理建议按环境管理不要写死在代码里。每次提示词改动都要版本化并且必须跑评测集回归确认改动没有破坏已通过的场景。很多团队把提示词当配置改完就上线结果某个场景悄悄崩了用户反馈了才知道。评测集是算法方案里最能体现工程能力的地方。至少要覆盖每个 P0 场景 20 条以上语料包括正例、反例、边界输入、攻击性输入。评测维度建议包含四类内容正确率、错误兜底率、无效工具调用率、单次会话 token 消耗。没有评测集的 Agent 项目算法优化就是凭感觉评审时我一般会直接追问评测集在哪没有就不给过。还有一个小点是基础算法能力的沉淀。Agent 的工具调用背后经常依赖搜索、匹配、剪枝、排序这类确定性算法跟模型能力是互补关系。能靠稳定算法解决的部分就不要让模型自由发挥这样既能提高稳定性也能省 token。一个典型例子是用户输入“帮我找到最近的门店”用规则解析加地理搜索比让模型直接输出门店结果要稳定得多。3.3 TC 评审怎么开检查清单和现场模拟技巧TC 评审在我们团队的定位是“上线前最后一道安全阀”。它不重复技术方案评审的细节重点看的是跨系统的稳定性、可维护性和技术债。TC 评审常见的翻车现场有三类。第一类是只有架构图没有任何指标问可用性目标、容量评估、成本估算全都没有。第二类是拿第三方模型能力当产品承诺比如评测集问题是“参考了某公开榜单排名所以效果一定好”但实际产品场景跟榜单场景差异巨大。第三类是技术债清单缺失上线前堆了一堆 TODO但没有人登记责任人。为了避免翻车我整理了一张 TC 评审检查清单每次线上会前先让项目组逐项自评可用性目标目标 QPS、响应时长 P95、可用性 SLA 是多少容量与并发模型网关限流值、工具调用并发上限、数据库连接估算成本估算单次会话平均 token 消耗、月度模型调用成本、缓存命中率目标安全边界Agent 能访问哪些数据、能操作哪些工具、是否有越权风险数据留存会话日志留存多久、是否脱敏、是否满足隐私要求观测与告警核心指标是否接入监控、异常是否有告警、trace 是否完善修复与回滚已知问题清单、每个问题的影响范围、回滚触发条件和负责人还有一个很有效的评审技巧现场模拟一个失败场景看项目组能不能答得清楚。比如问“如果模型在高峰期连续返回空结果 3 分钟你的系统怎么表现”技术负责人如果只能说“会加一个重试”基本说明方案没想透。完整回答应该是“重试一次 - 降级到小模型 - 再失败走人工话术 - 同时告警通知值班人”链路清晰责任到人。TC 评审的记录也要规范化风险登记表里每一项都必须有严重等级、影响范围、负责人、修复时限。没有闭环的风险项下次评审继续出现TC 就成了走过场。4. 评审会上一定会吵起来的五个问题以及我们踩过的坑无论评审链路定得多清楚真开起会来还是会有几类问题反复出现。我把这些问题和对应的处理方法整理出来基本可以直接拿来用。4.1 一定会吵起来的五个问题第一个问题是产品说“AI 必须保证成功”开发说“模型没法保证”。化解方式是用 P0/P1 能力矩阵。P0 场景是底线场景必须达到评测集准确率标准P1 场景是加分项达到基础可用即可。双方对着能力矩阵逐条核对而不是在会议室里抽象争论“AI 到底行不行”。第二个问题是 QA 问“Agent 行为是概率性的测试怎么测”。化解方式是允许 QA 放弃“断言输出是否相等”的思路改用行为指标加影子模式。也就是把正确性验证拆成多个维度意图识别是否对、工具调用是否对、策略是否命中、语气是否合规每个维度单独建立打分规则。第三个问题是“模型 API 成本太高谁来承担”。化解方式是单次会话预算控制给每条用户消息设定 token 上限超过就自动压缩上下文或者切换到轻量模型。再加一层缓存常见问答直接命中缓存不调用大模型。第四个问题是“要不要同时上多语言、多模态需求”。化解方式是做能力开关技术方案里把多语言、多模态拆成独立能力模块通过配置开关分阶段上线评审时只承诺当前开关打开的部分。第五个问题是 TC 发现技术债太多还能不能上。化解方式是把“分期重构、独立开关、回滚条件”作为通过 TC 的前置条件让技术债变成有计划的偿还而不是无限延期。4.2 我们踩过的典型坑第一个坑是把 Prompt 当配置文件结果线上出问题没法热修。后来 Prompt 全量走配置中心每次改动记录版本号并绑定评测集报告出问题直接回滚到上一版。第二个坑是拿公开榜单的模型成绩写进评审承诺。团队内部一度用“某模型在推理榜上排名很高”作为选型依据结果产品场景跟榜单场景差距巨大实际效果惨不忍睹。之后所有模型能力一律以自建评测集结果为准。第三个坑是忽略上下文窗口与长期记忆。多轮对话里用户经常前面说“我上笔订单”后面说“这个也一样”如果系统没有把历史信息正确组装进上下文Agent 就会失忆。后来加了会话记忆模块每次组装上下文时做关键信息提取效果立刻上了一个台阶。第四个坑是权限边界没定义清楚。Agent 能调用的工具权限一开始写得太宽差点出现越权操作后来所有工具接入必须走权限申请和审计日志默认拒绝一切未授权调用。Agent 项目的安全边界需要前置设计不能等出了问题再补。第五个坑是缺少仿真环境联调时把测试数据打到了线上工具里。后来搭了独立的 mock 工具服务线上和测试环境完全隔离类似事故没有再发生。这一条尤其适合做 IDE 插件类工具 Agent 的团队借鉴。4.3 评审后的快速验证手段评审通过不代表项目就稳了上线前的验证手段同样重要。我们常用的是四板斧。影子模式是最安全的验证方式把真实流量复制一份给新版本 Agent 跑但结果不直接触达用户用来观察行为差异。A/B 评测适合版本迭代同一批评测语料同时跑基线版和新版直接对比指标省时省力。trace 分析重点看工具调用失败率、无效调用率和异常兜底率这三个指标能快速暴露模型与工具之间的配合问题。回滚开关也要提前准备好模型输出异常或指标跌破阈值时一键切换到人工兜底话术等定位完问题再放开流量。这些验证手段产生的数据刚好可以作为下一轮评审的输入。Agent 项目本质上是个持续迭代的项目评审不是一次性关卡而是每一轮的校准点。如果非要说这套评审流程里最值钱的是什么我觉得不是流程本身而是强制把“不确定”变成“可讨论”的模板。每次开评审都对着同一套字段逐条过会开着开着结论就自然出来了。我个人现在的习惯是任何 Agent 项目立项前先花两小时填预评审模板哪怕只是内部自审也能提前挡掉一半需求。最后分享一个特别实在的操作技巧把评审通过的 Checklist 固化成一个团队模板库每次新项目直接复制旧文档改改比从零开始写快得多而且不会漏项。这套链路跑顺之后Agent 项目的评审从“疑难杂症”变成了“流水线作业”团队的效率和稳定性都会有质的变化。
