1. 需求拆解从模糊诉求到能力边界1.1 先搞清楚研发 Agent 到底替代谁的工作最近大半年我听到最多的一个问题是“我想做个研发 Agent帮我团队提效。” 每次听到这句话我的第一反应从来不是“用什么框架”而是“你这 Agent 到底想替谁干活、干到什么程度、谁为最终结果负责”。这三个问题不回答清楚后面所有架构设计都是空中楼阁。研发场景里的 Agent和我们平时刷到的聊天机器人完全是两回事。聊天机器人只需要“说得好”研发 Agent 必须“做得对”。它面对的是开发、测试、运维、文档这四类角色每一类又能拆出大量子任务。拿开发来说代码生成、代码审查、单测编写、缺陷定位、重构建议这些都是可以做 Agent 化的方向但每个方向对准确率、上下文长度、工具调用能力的要求完全不同。比如“代码审查”要求 Agent 能看懂 diff 上下文、能查历史提交、能对接静态检查工具“单测生成”则要求 Agent 能读代码、能执行测试、能看覆盖率报告。这两个看起来都是“开发场景”但能力栈的重叠度其实很低。我见过太多团队一上来就规划一个“全流程研发 Agent”从需求分析一路做到自动化部署结果做了三个月发现每个环节都是半吊子。正确的做法是先做岗位拆解再对每个子任务评估三个维度价值密度、风险等级、验证成本。价值密度指这个任务做 Agent 化后能节省多少人工风险等级指 Agent 出错后的影响面是“生成一段可修改的草稿”还是“直接改生产代码”验证成本指有没有自动化的手段判断 Agent 做得好不好比如单测能不能跑过、代码能不能编译、覆盖率有没有提升。这里给一个我常用的任务拆解模板。先列出研发全流程的所有环节再用“人工耗时占比”和“流程标准化程度”两个坐标给环节排序。人工耗时高且标准化程度高的环节是 Agent 化的最优切入点典型的例子是接口文档生成、单测补全、依赖升级影响的代码改动。人工耗时高但标准化程度低的环节比如复杂业务需求的方案设计可以做“辅助建议”而不是“自动执行”。人工耗时低但标准化程度高的环节比如格式化、排序用脚本就够了不必动用大模型。标准化程度低且人工耗时也低的环节暂时不要碰。1.2 需求优先级与能力边界能做的、不能做的、坚决不做的企业级 Agent 和开源 Demo 最大的区别是必须有能力边界。开源 Demo 可以什么都聊企业 Agent 必须明确哪些输入要接、哪些输入要拒、哪些操作需要人工确认、哪些操作坚决不允许执行。这个边界不是技术问题是需求规格问题。我在项目启动初期会强制团队写一份“Agent 能力清单”格式很简单分四列能力项、输入、输出、失败兜底。比如“单测生成”这一项输入是“代码文件路径 测试框架类型”输出是“单测代码 本地执行结果”失败兜底是“生成结果无法通过语法检查时输出诊断信息而不是强行断言”。这份清单的作用有两个一是给开发团队对齐方向二是给评测团队提供用例设计的依据。有一个很典型的反面教材。我们团队早期做过一个“需求文档自动生成 Agent”产品经理给的需求是“上传会议纪要自动生成需求规格说明书”。听起来很美好实际做出来效果一塌糊涂。原因不是模型能力不行而是需求的本质搞错了。需求规格说明书的核心价值在于记录决策脉络为什么做、为什么不这么做、验收标准是什么、风险和依赖有哪些。这些信息大部分不会出现在会议纪要里而是藏在参与者的脑子里。让 Agent 从一段零散的会议记录去“补全”这些内容时它只能靠猜测而需求文档最怕的就是猜测。后来我们把需求拆成了三个子任务会议纪要到结构化行动项、结构化行动项到用户故事、用户故事到验收标准草案。Agent 只负责第一层和第三层的机械性工作中间那一层必须由产品经理人工决策。拆完之后效果明显提升因为每个子任务的输入输出都变成了确定性的模型不需要承担它承担不了的设计职责。所以说需求拆解的核心不是“让 Agent 做更多”而是“让 Agent 做对它该做的把决策权留在人手里”。这不是能力妥协而是工程理性。另一个我踩过的坑是低估了“需求变更”对 Agent 系统的冲击。传统软件的变更管理有一套成熟机制但 Agent 系统里一个需求的变更往往意味着提示词、工具参数、校验规则、评测集全链路都要跟着动。如果没有一套“需求冻结”机制开发团队会被各种“顺手改一下”的需求打散节奏。我的做法是每周固定一个时间窗口集中评审能力变更窗口之外的需求先记入 backlog下个迭代再排期。2. 架构选型单体 Agent 和多智能体的权衡2.1 单体 Agent 跑全流程的痛你迟早会碰到很多团队做 Agent 的第一版走的是“一个 Agent 一堆工具”的路线把工具注册给 Agent让大模型自己决定调哪个、按什么顺序调。这个方案在最早期验证可行性时完全没问题它写起来快、调试直观、还能快速验证模型的基础工具调用能力。但一旦流程变长问题就被放大了。我称这类单体 Agent 为“瑞士军刀模式”什么都能干一点但每个任务都干不深。研发场景里一个典型任务链路是理解需求 → 拆解任务 → 搜索相关代码 → 编写代码 → 执行构建 → 修编译错误 → 跑测试 → 改测试失败 → 提交 MR。这条链路有 8 个以上的环节单个 Agent 要在一个上下文窗口里维护所有状态。模型不是超人当上下文很长时它的注意力会明显衰减。我实测过一个代码生成任务前 2K token 的上下文里模型表现稳定塞到 8K 以上时开始忽略前面的约束条件生成结果越来越“自作主张”。单体 Agent 的另一个痛点是权限控制粒度太粗。同一个 Agent 既要读代码仓库又要执行测试命令还要提交 MR。如果你给它整套权限它一旦在某个环节被误导或被注入恶意指令风险是整个仓库如果权限给得太少它连基本的代码搜索都做不了。这个矛盾在单体架构里基本无解。还有一个被忽视的问题单体 Agent 的每一步工具调用都会产生大量中间输出这些输出会污染上下文。比如 Agent 执行一个静态检查工具返回了 300 行警告信息。这 300 行对最终决策有用的可能只有 30 行但剩下的 270 行会占据大量上下文空间还可能干扰模型对后续指令的理解。在实际运行中我遇到过模型把静态检查的警告当成了“需要修复的 bug”来处理的乌龙原因就是上下文里工具输出和用户指令混在一起模型分不清主次。2.2 多智能体加编排层主管负责拆专家负责干研发场景的复杂性决定了单体 Agent 很难用好于是我们转向了多智能体架构。业界对这个架构有很多叫法主管-员工模式、老师-学生模式、规划师-执行者模式本质都是同一个思想把“决策”和“执行”分开。我的整体设计里采用“主管 Agent 多个专家子 Agent 编排层”的结构。主管 Agent 负责接收用户的任务描述理解需求后把任务拆解成子任务并决定每个子任务交给哪个专家 Agent 处理。专家 Agent 各管一摊代码生成 Agent 只写代码测试 Agent 只跑测试和修复失败用例审查 Agent 只做代码评审它们不需要关心完整流程只需要在自己的专业领域把一件事做到最好。编排层负责流程控制决定下一步该执行哪个节点、在什么条件下循环、在什么条件下终止。这个架构在系统层面带来三个直接收益。第一上下文隔离每个子 Agent 只看到与自己任务相关的输入输出不被全流程的中间信息干扰。第二权限细粒度化生成 Agent 只有代码仓库的只读权限测试 Agent 只能执行测试沙箱里的命令提交 MR 的操作专门由一个低权限的“执行 Agent”负责每一步都有明确的操作边界。第三可扩展性你想新增一个能力时不需要修改已有的核心逻辑只需要注册一个新的专家 Agent并在主管的编排规则里加上对应的路由分支。这里有一个很重要的概念区分harness 和 Agent 不是一回事。很多初学者把这两个词混着用导致沟通成本很高。Harness 是执行框架负责状态的流转、节点的调度、重试策略、结果聚合这些“流程基础设施”Agent 是决策单元负责理解和推理、工具选择、结果判断这些“智能部分”。你还是可以既有 harness 又有 agentharness 决定“什么时候调 agent”agent 决定“这一步具体怎么做”。在 LangChain 和 LangGraph 的组合里LangGraph 承担 harness 的角色而每个节点内部再使用 LangChain 提供的 Agent 实现。这个组合在技术社区里常被称为 harness 架构也是我当前在各种企业级项目里比较推荐的方案。2.3 流程模式选择流水线和动态规划怎么配多智能体的编排不是只有一种形态。我把实际项目中能用到的编排模式归成两类流水线模式和动态规划模式。流水线模式适合步骤固定、顺序明确的任务。比如“提交 MR 前自动生成单测”这个场景步骤永远是读改动文件 → 生成单测 → 本地跑测试 → 测试通过后追加提交。每一步的输入输出都是明确的不需要模型做复杂的路径规划。这种模式的好处是稳定、易调试、每一步都可以精确控制坏处是不够灵活一旦任务中间出现预期外的情况整条流水线就卡住了。动态规划模式适合任务中途可能出现分支、需要根据中间结果动态调整后续步骤的场景。比如“修复一个线上 bug”这个任务Agent 可能需要先看日志、再定位代码、再尝试修复、再回归测试任何一步都可能改变后续的路径计划是赶不上变化的。这种模式下编排层只定义“有哪些节点、节点之间允许怎么转移”具体路径由主管 Agent 根据当前状态实时决策。坏处是确定性差同样的输入可能走出不同的执行路径对评测和问题排查都是个挑战。企业落地建议能走流水线就走流水线只在局部节点引入动态决策。比如一个大流程可以拆成“需求结构化 → 方案生成 → 代码实现 → 测试验证”四个阶段前三个阶段的内部可以用动态规划让 Agent 自由探索但阶段之间的转移必须走确定性路由。这样既保留了 Agent 的灵活性又不会让整个流程失去控制。我在项目里经常看到团队把 All Agents 都放在一张大图里自由路由看起来很美跑起来全是不可控的分支最后只能靠不断的重试来维持可用性。3. 技能与工具层Agent 真正干活的细节拆解3.1 Skill 和 Agent 的边界别再混为一谈了最近技术圈里 Skill 这个词非常火但我发现很多人对 Skill 和 Agent 的关系还没理清楚导致开发出来的系统边界模糊、维护困难。我个人的理解是Skill 是能力包Agent 是执行体。具体来说Skill 是对“一个完整操作过程”的封装它包含三部分内容一是触发条件和输入模板告诉系统在什么场景下该用这个技能二是操作步骤序列可能是一段提示词加几个工具调用的组合定义了“先做什么、再做什么、中间如何做判断”三是输出校验规则定义什么样的输出算是合格的、什么情况下需要重试或上报失败。Agent 则是把这些 Skill 组装起来、并根据实际情况动态选择和执行 Skill 的智能体。打个比方Agent 是员工Skill 是员工手上的工作手册和工具包。员工可以按照手册完成一项任务也可以结合自己的判断在多个手册之间切换但手册本身是独立于员工存在的资产。这也意味着同一个 Skill 可以被多个不同职责的 Agent 复用。我可以在“代码生成 Agent”和“测试生成 Agent”里同时挂载一个“代码结构解析 Skill”这个 Skill 的作用是输入一段代码输出它的类、方法、依赖关系图两个 Agent 都可以用。在设计 Skill 时最关键的要点是“步骤显性化”。不要写那种“根据代码生成高质量单测”这种模糊的描述要拆成一步步可执行的动作第一步调用静态解析工具获取函数列表第二步过滤不需要测试的函数第三步按函数维度生成测试用例框架第四步填充测试断言第五步执行测试命令并收集通过率。步骤越细模型越容易执行评测也越容易定位是哪一步出了问题。3.2 企业工具集成与安全管控权限最小化是一条铁律研发 Agent 如果只停留在对话层面它是产生不了实际价值的。它必须能真正操作企业的研发工具链代码仓库、CI/CD 流水线、缺陷管理系统、文档平台、制品库。每一类工具的接入方式、权限模型、失败处理策略都不一样这块是项目里最耗时但也最不能省的部分。我画一张表来展示实际项目里的集成清单工具类型常见选型Agent 需要的操作权限最小化策略是否需要人工确认代码仓库GitLab / GitHub / Gitea搜索代码、查看文件、创建 MRToken 只授权指定仓库只读为主必须写操作时使用独立账号创建 MR 是合并到主干是其他否CI/CDJenkins / GitLab CI触发流水线、查看日志只授权指定 Job 的触发权限触发正式发布流水线是其余否静态检查SonarQube / ESLint / SpotBugs触发检查、获取报告只读 token否测试平台Pytest / JUnit / 自研框架执行测试、读取结果在隔离沙箱中执行不连接生产环境执行破坏性测试用例是其余否缺陷管理Jira / 禅道读取需求回填缺陷只读为主回填操作需要专用 token回填外部可见信息是安全管控方面我有一条铁律Agent 的每个操作都要遵循权限最小化原则。你可以给 Agent 的 GitLab Token 只开放“指定仓库、指定分支的读取权限”这就够了它写代码时只需要读取现有代码来理解上下文真正把改动提交上去的是另一个专门负责“提交”的低权限执行器。这里不是不信任模型而是模型可能被提示注入攻击、可能在长上下文中丢失约束、可能因为幻觉生成了不该执行的指令系统设计上必须把这些风险兜住。3.3 不同研发领域的差异化处理不仅仅是写代码研发 Agent 不是只有互联网软件研发这一种形态。热词里出现的 C51 单片机串口升级架构、PCB 设计、智能工厂规划总师这些是硬件和嵌入式领域的典型场景。我在这些领域也有过 Agent 化的尝试经验是要充分尊重各自领域的工具链和数据格式。嵌入式领域代码运行的硬件环境差异极大Agent 生成的代码要能编译通过就必须知道目标芯片的型号、编译器版本、链接脚本路径。这意味着 Agent 的工具层必须能动态获取这些环境信息并在生成代码前进行语法和链接检查。C51 系列的串口升级场景里固件升级包的格式校验、Bootloader 的交互时序这些都可以做成 Skill让 Agent 按照既定时序生成升级脚本或检测代码但底层的烧录动作必须有人工确认。PCB 设计领域的 Agent 化就更有意思了。PCB 设计的核心产出是电路原理图和布线文件这些是结构化的设计数据不是自然语言文本。想让 Agent 参与设计第一步不是训练它画线而是把设计规则、元器件库、电磁兼容约束这些内容做成可查询、可校验的工具接口。Agent 可以在布线完成后自动做设计规则检查DRC并给出修复建议但最终提交厂商生产前必须由资深硬件工程师签字确认。这其实就是“辅助建议”和“自动执行”的边界问题。4. 技术栈与代码落地从 LangGraph 到可运维系统4.1 技术选型为什么不建议完全自研技术选型这块我纠结过挺久最后定下来的方案是 LangChain 加 LangGraph 的组合而不是纯自研或纯用某一个框架。先说说为什么不用纯 LangChain。LangChain 本质上是把调用大模型、管理提示词、串联工具这些基本操作做了封装开发效率很高。但它对复杂流程的支持偏弱只能做线性的链式调用要做循环、条件分支、人机协同这些企业级 Agent 必须的能力写起来非常别扭。LangGraph 则把流程控制抽象成了图结构节点是操作边是转移条件这就把“流程状态管理”变成了一个可编程的模型和我的多智能体设计天然匹配。再说为什么不完全自研。自研的好处是自由度最高但代价是所有的轮子都要自己造状态管理、重试机制、可观测性、工具注册、评测框架这些都属于“不做项目时觉得很简单做起来才知道里面有大量细节”的东西。对一个企业项目来说时间成本完全不可接受。LangChain 加 LangGraph 的组合相当于拿到了一个成熟的社区解决方案生态里已经有很多现成的工具集成和最佳实践可以参考可以保证我们团队的精力集中在业务逻辑上而不是框架本身。当然如果你的团队深度绑定 Java 技术栈又不愿意部署一套 Python 服务那 Spring AI 加上 Camunda 这类工作流引擎也是一个可以参考的路线。但我的经验是在 Agent 领域的生态丰富度和迭代速度上Python 生态目前还是领先的建议先用 Python 验证业务闭环再考虑异构系统的对接。4.2 核心代码骨架一个主管加两个专家的最小实现我直接贴一段简化版的核心代码框架这就是上文说的“主管拆任务、专家执行”的最小实现可以用来搭出一个可用版本后续再逐步补充企业级细节。from typing import TypedDict, List from langgraph.graph import StateGraph, END from langchain_core.messages import HumanMessage, SystemMessage # 定义全局状态所有节点的输入输出都统一挂在这里 class AgentState(TypedDict): task: str # 用户原始需求 subtasks: List[str] # 主管拆解后的子任务 code_result: str # 代码生成节点的输出 test_result: str # 测试执行节点的输出 steps: List[str] # 执行轨迹用于可观测性 # 1. 主管节点负责任务拆解和分配 def supervisor_node(state: AgentState) - AgentState: prompt f 你是研发主管 Agent。请将下面的任务拆解为最多两个子任务 1. 如果任务涉及写代码输出子任务generate_code 2. 如果任务涉及验证输出子任务run_test 只输出 JSON 数组例如 [generate_code]。 任务{state[task]} llm get_llm_model() # 接入实际的大模型 response llm.invoke([SystemMessage(contentprompt)]) subtasks parse_json_array(response.content) return {subtasks: subtasks, steps: state[steps] [supervisor 拆解任务]} # 2. 代码生成专家节点 def generate_code_node(state: AgentState) - AgentState: if generate_code not in state[subtasks]: return state code call_code_generation_skill(state[task]) # 内部调用代码生成 Skill return {code_result: code, steps: state[steps] [generate_code 完成]} # 3. 测试执行专家节点 def run_test_node(state: AgentState) - AgentState: if run_test not in state[subtasks] or not state[code_result]: return state test_report run_tests_in_sandbox(state[code_result]) # 在沙箱中跑测试 return {test_result: test_report, steps: state[steps] [run_test 完成]} # 4. 是否执行测试的条件路由只有生成了代码才需要跑测试 def should_run_test(state: AgentState) - str: if run_test in state[subtasks] and state.get(code_result): return run_test return end # 5. 编排层把节点和边组装成图 graph StateGraph(AgentState) graph.add_node(supervisor, supervisor_node) graph.add_node(generate_code, generate_code_node) graph.add_node(run_test, run_test_node) graph.set_entry_point(supervisor) graph.add_edge(supervisor, generate_code) graph.add_conditional_edges(generate_code, should_run_test, {run_test: run_test, end: END}) graph.add_edge(run_test, END) app graph.compile()这段代码里有几个值得细看的设计点。首先所有节点的输入输出都通过AgentState传递没有节点之间直接通信这是多智能体系统里很关键的一个约束。如果子 Agent 之间互相直接调用流程会变得不可控所有信息流都必须经过全局状态这个“总线”。其次should_run_test是一个确定性函数它根据subtasks里有没有run_test来决定是否走测试节点这一步用的是规则而不是模型推理目的是降低不确定路径的出现概率。4.3 状态管理、可观测性与成本控制上了生产才明白的必修课开发环境的 Agent 原型和在生产环境跑的企业 Agent差别最大的地方不在模型本身而在状态管理、可观测性和成本控制这三件事上。状态管理方面我强烈建议把 Agent 的一次完整任务执行看成一个“状态机”每一步节点执行完都要把状态持久化下来而不是只存在内存里。这样即使进程崩溃也能从最近的检查点恢复执行避免重新跑一遍完整流程。我用 MySQL 存任务元数据用 Redis 缓存中间结果。比如一个代码检索节点如果多次任务查的是同一个文件直接把结果缓存起来既省了模型调用费用也降低了耗时。Redis 在高并发场景下还会承担一个更重要的职责控制并发限流防止大量 Agent 任务同时涌向大模型接口触发限流。可观测性是另一个容易踩坑的地方。Lineage 级别的日志记录是必须的每次任务执行要记录用户的原始输入、主管拆解出的子任务列表、每个子 Agent 的输入输出摘要、每次工具调用的入参和返回值、模型名称及 token 消耗、完整执行耗时。这些数据拼在一起你才能回答“这次任务为什么会失败”这种最基本的问题。成本控制方面有个常用策略分级使用模型。简单任务比如关键词提取、格式判断用小模型复杂任务比如代码生成、方案设计用大模型。实际项目里 40% 的 token 消耗其实花在了低难度节点上改用便宜模型后成本能降低一半以上。具体的分级策略要结合任务评测效果来定不能盲目贪便宜影响精度。5. 常见问题、BUG 排查与评测实录5.1 输出不稳定模型不是随机是缺少约束在大模型 Agent 项目中被问得最多的问题就是“为什么同样一个任务上次能成功这次就失败了”。这里最关键的认知是大模型的输出天然具有概率性你要做的不是指望它每次都“想对”而是通过系统设计让它“做不到错”。我总结了一套稳定化输出的组合拳。第一降低温度参数代码生成和工具调用这类任务温度设置到 0.1 以下逻辑类任务甚至可以直接设 0让模型输出尽可能确定。第二强制输出结构所有模型输出必须走结构化格式比如 JSON Schema 或 Pydantic 模型格式解析失败就自动重试一次而不是直接把原始文本交给下游处理。第三给足判例性示例光说“请生成单测”不够要在提示词里附上两到三个正反示例模型会照着示例的模式进行输出。第四在关键节点增加校验器比如生成代码后先做编译检查通过才放行不通过就带着错误信息重试一次。这四招里第三招“判例性示例”的效果最明显。有一次我们做 API 集成测试用例生成初始版本模型的输出总是漏掉异常分支的用例后来在 Skill 的提示词里补了两个含异常场景的示例问题解决率直接提升了 35% 左右。5.2 上下文污染工具输出是拿来用的不是拿来堆的这个问题非常普遍我在前面提到了单体 Agent 会被工具输出干扰实际上多智能体系统里一样会遇到只是范围缩小到了节点级别。一个测试节点如果直接让模型处理 300 行构建日志然后让它在同一轮对话里判断“测试是否通过”模型大概率会被日志中间的一些 warning 带偏。我现在统一采用“摘要后置”策略凡是工具返回的长内容第一版原样入库但送进模型前必须做摘要截断。摘要也有讲究不用大模型去读全文做摘要那样成本太高用规则匹配就行。比如构建日志只保留 error 和 failed 相关的行覆盖率报告只保留总体统计和未覆盖文件列表Git 提交记录只保留最近 5 条。这些经过滤的输出再传给 Agent 做决策。另一个和上下文相关的坑是 Agent 容易把工具输出当成最终答案。有一次测试 Agent 执行完单测后直接把测试命令的回显“Process finished with exit code 0”当成“测试通过”返回了但实际上测试成功率是 0%因为它压根没跑起来。这类问题靠提示词解决不了要在编排层加一道“验证节点”执行完测试命令后必须再调一次结果解析工具拿到“测试用例总数、通过数、失败数”三个数字如果解析失败就标记为异常。5.3 性能瓶颈与并发控制别让大模型接口成为单点企业级 Agent 一旦同时跑几十个任务大模型接口的延迟和限流立刻成了瓶颈。解决思路是能用规则解决的就不调模型能并行调用的就不串行。规则优先这一点再强调都不为过比如判断一个代码片段是否包含某个 API 调用用字符串匹配就行完全不需要模型推理。任务队列是另一个必备组件。Agent 的每个子任务本质上都是异步的前端提交一个需求后系统先把任务写入队列然后由 workers 池消费每个 worker 负责跑一条图执行链路。这个设计的好处是高峰期任务堆积时优先级高的任务可以插队而不是所有任务一视同仁地排队。我还会把“热路径”上的结果高频缓存到 Redis。比如代码仓库结构解析这个操作如果仓库不经常变那解析结果就可以缓存几十分钟省掉的重复解析也省掉了重复的模型调用。MySQL 存任务元数据Redis 当缓存和队列中间件再把大模型接口调用单独封装一层做限流和重试这套组合足够支撑中小规模团队的研发 Agent 日常使用。5.4 评测体系Agent 上线前的最后一道关卡Agent 评测Agent Evals是很多团队最容易忽略的环节。传统软件的单元测试还可以断言函数返回值Agent 的输出是开放性的文本和动态执行结果怎么自动判断它对不对我的经验是不要试图用一个统一标准评测所有任务要按 Skill 维度分别建立评测集。举个例子代码生成 Skill 的评测集可以包含这几类用例正常需求例如“写一个二分查找函数”、含约束需求例如“用递归实现且不使用额外数组”、边界异常需求例如“输入为 null 或空数组”。每个用例标注标准答案和关键考查点执行 Agent 后自动检查代码能不能编译、执行结果是否正确、是否满足约束条件。开放式任务的评测用“LLM-as-judge”的方法让一个 GPT 级别的强模型当评委把任务描述、Agent 输出、评分标准传给评委模型让它给出分值和理由。但这个方法有个前提评委模型必须在评测集上做过人机一致性验证否则评委自身的偏差会被带进评测体系。另外给评委模型的打分标准要拆成多个维度比如完整性、正确性、可维护性而不是给一个笼统的 1 到 10 分。评测不能只在开发阶段做一次。Agent 系统的特点是模型升级、提示词调整、工具参数变化任何一个环节变了整体效果都可能波动。所以我的习惯是建立一套回归评测流水线每次代码变更后自动跑一遍核心集核心集大约覆盖 80 个典型用例全量集覆盖 300 个以上用例只有全量集通过率不低于基线的版本才允许合并到主分支。我在这块踩过最大的坑是评测标准定得太主观。早期评测“代码生成好不好看”完全依赖人肉看看起来很全面实际上完全没有可重复性同一段输出上午评为优秀、下午评为及格。后来把标准改成量化指标组合包括编译通过率、测试通过率、圈复杂度增量、是否违反代码规范情况才真正好转。6. 最后分享一点个人体会做了这么多企业 Agent 项目我最大的感受是Agent 架构设计的核心难点从来不在模型而在需求理解和系统约束。模型选型、框架选型都有成熟方案真正拉开差距的是需求拆解得够不够细、能力边界划得够不够清、评测体系建得够不够扎实。如果你正准备启动一个研发 Agent 项目我建议从第一天起就写好需求规格说明书把“Agent 能做什么、不能做什么、在哪里停下来等人工确认”用文字固化下来。这个文档的读者不只是你的开发团队还有业务方和管理层它能有效管理预期避免“Agent 什么都能干”这种幻觉蔓延。我见过太多项目因为一开始没把预期管住最后被“为什么这个需求没满足”的需求淹没。最后再分享一个小技巧企业级 Agent 的迭代节奏不要追求一步到位以两周为一个迭代周期每个迭代只强化一个垂直场景。第一个迭代做“单测生成”第二个迭代做“代码审查”第三个迭代做“缺陷定位”每个场景都跑通评测、权限、可观测性这个闭环再进入下一个。这样推进的节奏可能显得慢但每一步都是扎实的等到第六个迭代复盘时你会发现整个系统已经具备了非常完整的形态。