1. 别急着画架构图先想清楚企业研发 Agent 到底要承接什么需求近几年聊 Agent 的人很多但大部分讨论停留在智能体怎么调工具怎么接大模型的层面。我接手企业研发 Agent 这个设计任务时第一反应也是去找各种 agent 框架、对比 harness 和 agent 的区别。真正让我停下来重新思考的不是技术选型而是一个很朴素的问题企业研发场景里Agent 到底替谁干活、解决什么具体痛处我所在的环境是典型的多个项目组并行迭代产品、开发、测试、架构各角色每天产出大量需求文档、需求规格书、测试用例、变更记录。这些东西散落在不同系统里格式不统一互相之间没有关联。最典型的一幕一个需求从产品提出到开发交付中间要经过需求评审、技术方案、用例设计、回归验证每个环节都要重述一遍上下文项目一多同样类型的需求在 A 组和 B 组各写一份规格书用例也各自维护改一个逻辑要同步好几个地方漏一个就出线上问题。所以这个 Agent 的第一定位不是一个对话机器人而是一个研发过程的管理与执行载体。它要把需求怎么变成规格、规格怎么变成用例、用例怎么跟着需求变更走这条链路结构化、自动化、可复用。想清楚这一点之后架构设计才不会被带偏核心不是模型多聪明而是知识资产怎么组织、任务怎么拆解、流程怎么编排、结果怎么可信。从适用人群来说这个设计主要服务三类人产品经理输入一段需求描述Agent 辅助产出结构化需求规格书初稿并自动关联已有相似需求提示重复或冲突。研发工程师拿到规格书后Agent 按技术方案拆解开发任务生成代码变更范围分析和自测建议。测试工程师基于需求规格书自动生成测试用例并在迭代中识别用例变更点辅助回归测试策略。整个设计围绕一条主线展开需求驱动、架构承接、能力复用、结果可评估。下面的内容就是我在这条主线上从需求到架构的完整拆解不绕弯子直接讲我最后落地的方案。2. 从模糊诉求到能力边界三条主线把要什么翻译成做什么2.1 我的拆解方法先列场景再找共性最后定义能力很多 Agent 项目失败不是模型能力不行而是需求没有拆到能力层面。我采用的办法是把所有可能的使用场景全部列出来然后归并。比如把需求自动写成规格书和把变更描述更新到旧规格书表面上是两个功能但底层都依赖同一个能力对需求文本做结构化的信息抽取和逻辑校验。再比如生成测试用例和识别需求变更影响范围都依赖对需求粒度与业务规则的心智建模。归并到最后整个研发 Agent 的能力边界收敛成五块另外两块作为辅助支撑。我把它们整理成一张能力地图能力域解决的具体问题典型输入典型输出需求理解与结构化把零散需求转成标准条目会议纪要、PRD片段需求条目、验收标准规格书生成与维护需求到研发契约的转化需求条目需求规格书、变更说明测试用例生成规格到验证资产的转化规格书、历史用例测试用例、回归建议任务拆解与编排规格到执行计划规格书、技术方案开发任务、依赖关系知识复用与冲突检测跨项目组资产复用历史需求、用例库相似需求、冲突提示、复用建议辅助能力是权限控制和操作审计。企业在用 Agent 时最怕的不是它不够聪明而是它越权做事或者改错了没记录。所以治理能力不是加分项是底线。2.2 三条主线的逻辑关系这五块能力在实际架构中不是平铺的而是按照三条主线组织。主线一是需求到规格。这条线解决的是需求描述到结构化规格的转化。难点在于需求天然是模糊的比如订单超时未支付自动关闭并退款这句话规格书里必须回答超时时间是多少退款是原路退回吗部分退款怎么处理用户是否要收到通知Agent 不能猜必须通过上下文知识库和schema约束把不确定项列成待确认问题而不是自作主张填值。主线二是规格到用例。这条线解决的是验证资产的生成和维护。难点在于用例不是越多越好而是每条用例都能追溯到具体规则。我在设计里对用例生成做了强制约束每个技术规则点必须有正向用例和反向用例并且用例要标注关联的需求规则编号。这样需求一变更影响哪些用例一目了然。主线三是任务到执行。这条线解决的是研发工作中的流程编排。Agent 不能只负责出文档还要把文档变成可执行的任务推进到具体的人或自动化流水线。难点在于任务之间的依赖关系以及任务状态变更后的联动更新。这三条主线并不是项目启动后一次性走完而是在迭代中反复循环。所以架构上必须考虑一个事规格、用例、任务、需求之间要有血缘关系改一处能顺着链路找到所有受影响的资产。这是后面架构分层的一个关键约束。3. 整体架构第一版编排层、能力层、知识层和数据回流层怎么拆才合理3.1 分层总览整体架构我分了四层外加一条贯穿始终的治理通道。很多 agent 架构介绍会强调Agent 用什么框架、接了什么模型我的设计里这些属于编排层内部细节不是架构的骨架。骨架应该是一句话需求进来经过编排层拆解调度能力层完成任务知识层提供上下文数据回流层把过程沉淀下来。四个层次分别是交互接入层统一接收来自 Web 端、IDE 插件、命令行、IM 机器人等入口的请求做身份认证、参数校验和会话管理。编排控制层负责理解用户意图、规划任务步骤、调用能力层执行、汇总结果。这部分我基于 LangGraph 实现了有状态的工作流核心是让每一步都处于可观测、可回滚的状态。能力执行层屏蔽掉具体工具差异提供统一的 Skill 接口。每个 Skill 只做一件事比如解析需求文档生成规格书查询历史用例更新用例状态。知识资产层承载需求条目库、规格书库、用例库、领域词典、历史决策记录。这一层是整个 Agent 的记忆中枢也是跨项目组复用的基础。治理通道是横向的一个安全与审计服务所有层的关键操作都会把事件写入审计日志同时做细粒度的权限判断。我把它单独拎出来是因为研发场景里很多操作会落在真实代码仓库、需求系统、测试平台上权限错了后果很严重。3.2 编排层为什么选 LangGraph 而不是纯 LangChain编排层的选型我在 LangChain 和 LangGraph 之间犹豫过一阵。简单做一下区分LangChain 更像一个工具集合适合问一句答一句的简单场景LangGraph 则引入了节点、边、状态池和条件路由可以把一个复杂任务建模成有向图每个节点执行特定 Skill边表示状态流转。研发 Agent 的场景天然需要多步、带分支、可回退的流程。比如生成一份规格书不是一次大模型调用就完事而是解析需求 - 查重 - 识别缺失规则 - 生成条文 - 校验格式 - 生成待确认问题列表。中间任何一步发现信息不足都要回到追问节点而不是继续往下走。这种控制流用 LangGraph 建模很自然。关键设计上我把用户可见的结果和过程状态分开存储。LangGraph 的 State 里只保留任务执行状态不直接塞大量文本每个节点写结果时需要显式声明输出字段这样后续节点能明确知道自己拿到的数据长什么样。这个习惯帮我避了很多坑——Agent 场景里最常见的错误就是一个节点输出格式变了后面节点解析崩溃而且你还不知道是什么时候变的。3.3 能力层Skill 拆分的粒度标准Skill 是架构里最容易设计过度的地方。一开始我参考了不少案例把 Skill 拆得很细比如提取订单号识别金额字段判断用户角色结果是编排层光路由就写了一百多个分支维护成本直线上升。后来我定了一个粒度标准一个 Skill 必须能独立回答我要完成一个可验收的结果。比如生成测试用例是一个 Skill而提取页面元素不该是一个独立 Skill它只是生成用例过程中的一个步骤内部做掉就行。这样能力层最终收敛成二十多个 Skill每个 Skill 都包含输入schema、输出schema、内部执行逻辑和必要的校验规则。每个 Skill 内部也不是简单地调一次大模型而是规则 模型 模板 校验的组合。以需求规格书生成为例规则层根据需求类型功能、接口、数据、权限选择对应的规格书模板结构。模型层把需求文本和模板 schema 一起交给大模型产出一个结构化草稿。校验层用自定义规则检查必填字段、编号格式、涉及规则是否有歧义。人工介入点凡是校验未通过的条目统一进入待确认清单不强行输出。这套机制保证了 Agent 生成的东西不是看起来不错而是结构可用、字段完整、逻辑可追踪。3.4 知识层资产复用不是塞向量数据库那么简单跨项目组的需求规格书和测试用例复用是知识层最难的部分。很多人第一反应是把所有文档切片、embedding、塞进向量库然后做相似度检索。这个思路能用但撑不起企业级复用的要求。原因有几个文档格式不统一导致切片质量差相似需求可能表达不同语义版本变化无法追踪权限控制难做细。我的方案是以条目为最小单元以关系为骨架以向量检索为加速手段。需求规格书不按文档存而是按需求条目存每条有唯一编号、所属模块、版本、规则列表、状态。测试用例按用例条目存每条关联需求条目编号。这样构建出来的不是一堆碎片文本而是一张有结构的资产网络。向量检索在这里只负责召回候选之后必须经过规则过滤看版本是否匹配、权限是否允许、状态是否有效。这样既解决了语义召回问题又不会因为文本碎片导致上下文失控。4. 跨项目组复杂迭代里的需求规格与测试用例管理、复用、维护的架构落位4.1 复杂迭代的真正问题不是多而是变更传导多项目组并行迭代资产量一大最怕的不是存不下而是变更发生后不知道影响面。一个需求改了描述规格书要同步改测试用例要同步改开发任务要重新评估测试计划要调整回归范围。如果这些资产之间没有结构化的关联每次变更都是人肉搜索、人肉确认。所以在架构里我把变更传导当作一个一等公民来设计。需求条目状态从草稿变更为已确认时事件总线会触发三个动作关联的规格书版本生成一个待更新标记。关联的测试用例状态变为待回归。相关开发任务的描述里追加变更说明并通知任务负责人。这说起来简单落地需要有扎实的数据模型支撑。每条资产都包含标准字段资产ID、类型、版本、状态、来源条目ID、下游条目ID、变更时间、变更人、变更说明。维护好这些字段变更传导才有依据。4.2 复用策略不搞全自动推荐而是人工确认自动引用我之前试过让 Agent 在需求评审时自动推荐相似历史需求结果误报不少。后来把策略调整为双阶段复用。第一阶段是候选召回。需求解析完成后Agent 用语义相似度和关键词匹配双通道把可能与当前需求相关的历史条目找出来形成一个候选列表。第二阶段是关联确认。Agent 不直接把候选塞进当前需求而是生成一份复用建议报告说明每个候选条目的相似点、差异点、建议处理方式直接复用、改造复用、仅作参考。由需求负责人确认后才正式建立关联关系。这个设计看起来效率低了一点但正确率大幅提升。而且当关联关系建立之后后续的变更影响识别才有数据基础。宁可慢一步不能错一次在研发资产复用上这句话特别适用。4.3 测试用例的自动生成与人工修订闭环测试用例是复用和维护负担最重的一块。我的设计是Agent 根据规格书的规则点列表自动生成初始用例每条用例自动标注覆盖的规则编号。生成之后进入人工修订环节测试负责人修改后Agent 对比修改内容把差异回写为规则点补充反向补全规格书里可能缺失的验收标准。这个闭环的价值在于测试用例不再只是验证工具它变成了一种发现规格遗漏的手段。比如一个正常场景下规则点只写了超时关闭订单测试人员在用例里补了一条超时后用户重新支付成功订单重新开启Agent 捕捉到这个差异就会建议规格书补充异常恢复规则。这样测试和需求之间不再是单向消费而是互相增强。我在实际操作中发现闭环设计对提示词和 schema 的要求很高。提示词里必须明确告诉模型你现在生成的每条用例必须关联规格书中的规则编号如果找不到对应规则不要猜测而是标记为未覆盖规则。这个约束一加用例质量提升非常明显。5. 架构落地中最容易翻车的三个环节评估、权限、成本架构图人人会画真正让项目推进不下去的往往是三个隐性环节怎么证明 Agent 产出是好的、怎么控制它能做什么事、以及怎么把成本压到可接受范围。5.1 Agent 评估没有评测体系的 Agent 就是给自己挖坑没有评估体系的 Agent 项目后期一定失控。原因很好理解Agent 的行为空间比传统程序大得多同一个需求模型可能给你三种不同结构的输出没有评测你怎么判断哪个是对的我搭的评估体系分两个层次。第一层是单点评测也叫离线评测。我有一个人工标注的评测集覆盖需求解析、规格生成、用例生成等核心场景大概四百多条。每次升级模型或修改提示词后先跑一遍评测集用结构化字段准确率规则点覆盖率格式合规率这几个指标看效果有没有回退。这个集子的维护很重要每次线上发现的错误案例都要沉淀进来防止同一个坑以后反复踩。第二层是链路评测也叫在线评估。评测的不是单个节点的输出而是端到端的任务完成度。我会给 Agent 布置一个完整的模拟任务比如给一个订单退款需求生成规格书和配套用例并完成复用推荐然后从任务完成率、耗时、人工修正率三个维度打分。这里要提醒一点评测集不要只追求数量要追求场景覆盖的均衡性。我之前做过一个评测集里面正向用例特别多反向用例很少结果模型在异常处理场景的表现一直没被暴露上线后第一轮就有用户在变更影响范围识别上发现 Agent 漏判。后来重新配比了正常场景、边界场景、异常场景的比例问题才暴露出来并被修掉。5.2 权限设计Agent 的能力必须穿透到底层系统研发 Agent 要操作的真实系统包括代码仓库、需求管理平台、测试管理平台。这些系统本身有权限体系Agent 不能绕过它们直接操作。我的做法是Agent 在发起底层调用时必须携带三层身份信息用户身份、项目角色、操作终端。底层系统仍然执行自己的权限校验Agent 只是把用户的真实身份透传过去。这样做有三个好处审计日志能精准定位到人不同项目的同一用户能拿到不同的权限范围Agent 自身的越权行为能被底层系统拦截并记录下来。这个设计在架构图里容易被忽略但它决定 Agent 能不能真正用于企业生产环境。我见过不少 agent 项目POC 阶段一切正常一接入真实系统就被安全团队驳回原因就是权限模型没有想清楚。5.3 成本控制大模型调用是架构里最容易被低估的部分企业研发 Agent 和普通对话机器人不同一个任务的完成往往涉及多次模型调用。以生成一份规格书为例可能包含解析、查重、生成、校验、追问五六个节点每个节点都可能调用一次大模型。如果需求文本又长token 消耗非常可观。我的成本控制策略有三个能不用大模型就不不用大模型。规则能处理的校验、编号生成、字段格式检查一律写死成规则代码不调模型。优先用便宜模型做粗筛贵模型做精修。比如需求查重阶段先用低成本模型做语义粗筛把候选集缩小到五条以内再让更强模型做精细对比。所有模型的输入输出都做结构化压缩。长文档不整段塞给模型而是先抽取关键字段只传必要上下文控制 token 量。这一套策略执行下来单任务成本能比最初的版本降低百分之五十以上。省下来的预算可以用来做更好的评测集、更充分的线上灰度。6. 几个值得单独展开的权衡与取舍6.1 Harness 和 Agent 的分工不是越智能越好是越可控越好不少团队纠结于 Harness 和 Agent 的区别。我的理解是Harness 是一个受控的工作流框架它规定了每个环节的执行顺序、状态转移和异常处理方式每一步做什么都清晰可见Agent 则更强调自主决策模型可以根据情况自己决定下一步调用什么工具。在企业研发场景我最终的倾向是以 Harness 为主Agent 的自主性体现在局部。整个链路是编排好的但链路中的单个节点内部模型有自主能力。比如在需求解析节点模型可以决定用什么方式抽取规则点但在链路层面必须严格遵守解析 - 查重 - 生成 - 校验的顺序。这样既保留了模型的灵活性又让整个流程处于可控、可观测的状态。这个取舍很重要。研发环境里不可控的流程就是灾难。一次错误的自动提交、一个被误改的文档代价都不小。所以宁可牺牲一点端到端全自动的炫技感也要保证每一步都能被人审阅和打断。6.2 Skill 和 Agent 的边界把变化的部分藏在 Skill 内部Skill 和 Agent 的边界划定我参考了微服务架构里的高内聚、低耦合原则。Agent 只关心先干什么、后干什么、什么情况走分支Skill 只关心这一件事怎么高质量完成。Agent 不感知 Skill 内部用的是哪个模型、是不是调了外部 APISkill 也不感知当前任务的上文和下文只处理传入的结构化参数。这个边界带来一个实际的好处当某个环节的模型效果需要优化时我只改对应的 Skill不需要改动编排层。比如测试用例生成质量不达标我调 Skill 内的 prompt、补充它的校验规则就够了整个 Agent 的其他部分不受影响。这种隔离让迭代效率高了很多。6.3 全自动执念的修正人在环路Human-in-the-Loop不是退步是理性设计初期我也追求过需求进来、用例出去全程无人干预的效果。很快发现这不现实也不合理。需求里的业务决策、跨模块冲突、隐性约束模型很难独立判断而且就算模型判断对了团队也需要一个确认环节来建立对系统的信任。所以最终架构里我把每个关键节点都设成了半自动模式Agent 产出初稿 人工确认 反馈回流。人工确认不是简单点一下通过而是可以局部修改修改内容会被 Agent 学习并在下次生成时参考。这个设计等于把每个用户都变成了标注者。系统刚上线时人工介入比率高随着反馈数据积累介入比率逐渐下降。这是我认为企业研发 Agent 最务实的演进路径——没有捷径靠的是闭环数据和持续优化。7. 从 POC 到生产我踩过的几个代表性坑7.1 坑一过度依赖大模型做结构抽取导致输出不稳定最早做需求解析时我直接用大模型从长文本里抽字段结果同一个需求每次跑出来的字段多少不一样。后来改为规则先行文档先按章节和标题层级拆成分段每段再按类型匹配解析模板模板固定下来的字段由代码强制校验只有模板之外的内容才交给模型补充。这一改结构稳定性一下子上来了。这件事给我的教训是大模型的优势是理解语义劣势是精确执行。架构设计里尽量让模型做擅长的事把精确性要求高的部分交给规则代码。7.2 坑二上下文无限制拼接导致效果和成本双输早期版本为了追求生成质量我把历史需求、规格书、相关用例全部塞进上下文结果模型效果反而变差因为无关信息干扰了判断token 成本还暴增。后来采用分阶段取上下文的策略每个 Skill 只取自己需要的最小上下文集比如生成测试用例时只取需求条目、规则点列表和同模块历史用例样例不传完整规格书。效果和成本都明显改善。7.3 坑三没有版本管理的 Agent 配置就是不可复现的实验Agent 的提示词、Skill 逻辑、评测集、模型参数这些配置如果不做版本管理项目跑几个月后你根本不知道当前线上版本是怎么调出来的。我把所有配置纳入代码仓库管理每个版本都有对应的评测记录和上线说明。这样出现问题可以快速回滚对比也方便团队协作迭代。这套配置版本管理和传统软件工程的产物版本管理同等重要。没有它Agent 项目做久了就是一个黑盒没人敢动更没人能继承。8. 演进方向与个人体会整体架构跑通之后我最大的感受是企业研发 Agent 的价值不在于替代某一个岗位而在于把研发链条上的知识资产串起来。单个节点的自动化只是提效真正改变协作方式的是需求、规格、用例、任务之间形成的有机关联。这种关联一旦建立后续的变更评估、质量分析、资源调度都能站在更高维度去做。目前这套架构在团队里最受好评的能力反而不是自动生成规格书而是需求变更后自动告诉我哪些用例要回归、哪些模块要重新评估。因为这是人最耗时、最容易漏的地方Agent 恰好擅长。演进方向上我接下来会重点做两件事。一是把线上运行中积累的修正数据反馈到评测集让评估体系持续逼近真实场景二是探索多 Agent 协作模式下不同角色的分工而不是停留在单 Agent 完成任务的状态。整体思路是架构骨架不变能力和数据的闭环持续转起来让 Agent 在一次次迭代中变得更懂这个团队的研发习惯。 企业研发Agent架构设计：从需求规格到测试用例的落地实践
1. 别急着画架构图先想清楚企业研发 Agent 到底要承接什么需求近几年聊 Agent 的人很多但大部分讨论停留在智能体怎么调工具怎么接大模型的层面。我接手企业研发 Agent 这个设计任务时第一反应也是去找各种 agent 框架、对比 harness 和 agent 的区别。真正让我停下来重新思考的不是技术选型而是一个很朴素的问题企业研发场景里Agent 到底替谁干活、解决什么具体痛处我所在的环境是典型的多个项目组并行迭代产品、开发、测试、架构各角色每天产出大量需求文档、需求规格书、测试用例、变更记录。这些东西散落在不同系统里格式不统一互相之间没有关联。最典型的一幕一个需求从产品提出到开发交付中间要经过需求评审、技术方案、用例设计、回归验证每个环节都要重述一遍上下文项目一多同样类型的需求在 A 组和 B 组各写一份规格书用例也各自维护改一个逻辑要同步好几个地方漏一个就出线上问题。所以这个 Agent 的第一定位不是一个对话机器人而是一个研发过程的管理与执行载体。它要把需求怎么变成规格、规格怎么变成用例、用例怎么跟着需求变更走这条链路结构化、自动化、可复用。想清楚这一点之后架构设计才不会被带偏核心不是模型多聪明而是知识资产怎么组织、任务怎么拆解、流程怎么编排、结果怎么可信。从适用人群来说这个设计主要服务三类人产品经理输入一段需求描述Agent 辅助产出结构化需求规格书初稿并自动关联已有相似需求提示重复或冲突。研发工程师拿到规格书后Agent 按技术方案拆解开发任务生成代码变更范围分析和自测建议。测试工程师基于需求规格书自动生成测试用例并在迭代中识别用例变更点辅助回归测试策略。整个设计围绕一条主线展开需求驱动、架构承接、能力复用、结果可评估。下面的内容就是我在这条主线上从需求到架构的完整拆解不绕弯子直接讲我最后落地的方案。2. 从模糊诉求到能力边界三条主线把要什么翻译成做什么2.1 我的拆解方法先列场景再找共性最后定义能力很多 Agent 项目失败不是模型能力不行而是需求没有拆到能力层面。我采用的办法是把所有可能的使用场景全部列出来然后归并。比如把需求自动写成规格书和把变更描述更新到旧规格书表面上是两个功能但底层都依赖同一个能力对需求文本做结构化的信息抽取和逻辑校验。再比如生成测试用例和识别需求变更影响范围都依赖对需求粒度与业务规则的心智建模。归并到最后整个研发 Agent 的能力边界收敛成五块另外两块作为辅助支撑。我把它们整理成一张能力地图能力域解决的具体问题典型输入典型输出需求理解与结构化把零散需求转成标准条目会议纪要、PRD片段需求条目、验收标准规格书生成与维护需求到研发契约的转化需求条目需求规格书、变更说明测试用例生成规格到验证资产的转化规格书、历史用例测试用例、回归建议任务拆解与编排规格到执行计划规格书、技术方案开发任务、依赖关系知识复用与冲突检测跨项目组资产复用历史需求、用例库相似需求、冲突提示、复用建议辅助能力是权限控制和操作审计。企业在用 Agent 时最怕的不是它不够聪明而是它越权做事或者改错了没记录。所以治理能力不是加分项是底线。2.2 三条主线的逻辑关系这五块能力在实际架构中不是平铺的而是按照三条主线组织。主线一是需求到规格。这条线解决的是需求描述到结构化规格的转化。难点在于需求天然是模糊的比如订单超时未支付自动关闭并退款这句话规格书里必须回答超时时间是多少退款是原路退回吗部分退款怎么处理用户是否要收到通知Agent 不能猜必须通过上下文知识库和schema约束把不确定项列成待确认问题而不是自作主张填值。主线二是规格到用例。这条线解决的是验证资产的生成和维护。难点在于用例不是越多越好而是每条用例都能追溯到具体规则。我在设计里对用例生成做了强制约束每个技术规则点必须有正向用例和反向用例并且用例要标注关联的需求规则编号。这样需求一变更影响哪些用例一目了然。主线三是任务到执行。这条线解决的是研发工作中的流程编排。Agent 不能只负责出文档还要把文档变成可执行的任务推进到具体的人或自动化流水线。难点在于任务之间的依赖关系以及任务状态变更后的联动更新。这三条主线并不是项目启动后一次性走完而是在迭代中反复循环。所以架构上必须考虑一个事规格、用例、任务、需求之间要有血缘关系改一处能顺着链路找到所有受影响的资产。这是后面架构分层的一个关键约束。3. 整体架构第一版编排层、能力层、知识层和数据回流层怎么拆才合理3.1 分层总览整体架构我分了四层外加一条贯穿始终的治理通道。很多 agent 架构介绍会强调Agent 用什么框架、接了什么模型我的设计里这些属于编排层内部细节不是架构的骨架。骨架应该是一句话需求进来经过编排层拆解调度能力层完成任务知识层提供上下文数据回流层把过程沉淀下来。四个层次分别是交互接入层统一接收来自 Web 端、IDE 插件、命令行、IM 机器人等入口的请求做身份认证、参数校验和会话管理。编排控制层负责理解用户意图、规划任务步骤、调用能力层执行、汇总结果。这部分我基于 LangGraph 实现了有状态的工作流核心是让每一步都处于可观测、可回滚的状态。能力执行层屏蔽掉具体工具差异提供统一的 Skill 接口。每个 Skill 只做一件事比如解析需求文档生成规格书查询历史用例更新用例状态。知识资产层承载需求条目库、规格书库、用例库、领域词典、历史决策记录。这一层是整个 Agent 的记忆中枢也是跨项目组复用的基础。治理通道是横向的一个安全与审计服务所有层的关键操作都会把事件写入审计日志同时做细粒度的权限判断。我把它单独拎出来是因为研发场景里很多操作会落在真实代码仓库、需求系统、测试平台上权限错了后果很严重。3.2 编排层为什么选 LangGraph 而不是纯 LangChain编排层的选型我在 LangChain 和 LangGraph 之间犹豫过一阵。简单做一下区分LangChain 更像一个工具集合适合问一句答一句的简单场景LangGraph 则引入了节点、边、状态池和条件路由可以把一个复杂任务建模成有向图每个节点执行特定 Skill边表示状态流转。研发 Agent 的场景天然需要多步、带分支、可回退的流程。比如生成一份规格书不是一次大模型调用就完事而是解析需求 - 查重 - 识别缺失规则 - 生成条文 - 校验格式 - 生成待确认问题列表。中间任何一步发现信息不足都要回到追问节点而不是继续往下走。这种控制流用 LangGraph 建模很自然。关键设计上我把用户可见的结果和过程状态分开存储。LangGraph 的 State 里只保留任务执行状态不直接塞大量文本每个节点写结果时需要显式声明输出字段这样后续节点能明确知道自己拿到的数据长什么样。这个习惯帮我避了很多坑——Agent 场景里最常见的错误就是一个节点输出格式变了后面节点解析崩溃而且你还不知道是什么时候变的。3.3 能力层Skill 拆分的粒度标准Skill 是架构里最容易设计过度的地方。一开始我参考了不少案例把 Skill 拆得很细比如提取订单号识别金额字段判断用户角色结果是编排层光路由就写了一百多个分支维护成本直线上升。后来我定了一个粒度标准一个 Skill 必须能独立回答我要完成一个可验收的结果。比如生成测试用例是一个 Skill而提取页面元素不该是一个独立 Skill它只是生成用例过程中的一个步骤内部做掉就行。这样能力层最终收敛成二十多个 Skill每个 Skill 都包含输入schema、输出schema、内部执行逻辑和必要的校验规则。每个 Skill 内部也不是简单地调一次大模型而是规则 模型 模板 校验的组合。以需求规格书生成为例规则层根据需求类型功能、接口、数据、权限选择对应的规格书模板结构。模型层把需求文本和模板 schema 一起交给大模型产出一个结构化草稿。校验层用自定义规则检查必填字段、编号格式、涉及规则是否有歧义。人工介入点凡是校验未通过的条目统一进入待确认清单不强行输出。这套机制保证了 Agent 生成的东西不是看起来不错而是结构可用、字段完整、逻辑可追踪。3.4 知识层资产复用不是塞向量数据库那么简单跨项目组的需求规格书和测试用例复用是知识层最难的部分。很多人第一反应是把所有文档切片、embedding、塞进向量库然后做相似度检索。这个思路能用但撑不起企业级复用的要求。原因有几个文档格式不统一导致切片质量差相似需求可能表达不同语义版本变化无法追踪权限控制难做细。我的方案是以条目为最小单元以关系为骨架以向量检索为加速手段。需求规格书不按文档存而是按需求条目存每条有唯一编号、所属模块、版本、规则列表、状态。测试用例按用例条目存每条关联需求条目编号。这样构建出来的不是一堆碎片文本而是一张有结构的资产网络。向量检索在这里只负责召回候选之后必须经过规则过滤看版本是否匹配、权限是否允许、状态是否有效。这样既解决了语义召回问题又不会因为文本碎片导致上下文失控。4. 跨项目组复杂迭代里的需求规格与测试用例管理、复用、维护的架构落位4.1 复杂迭代的真正问题不是多而是变更传导多项目组并行迭代资产量一大最怕的不是存不下而是变更发生后不知道影响面。一个需求改了描述规格书要同步改测试用例要同步改开发任务要重新评估测试计划要调整回归范围。如果这些资产之间没有结构化的关联每次变更都是人肉搜索、人肉确认。所以在架构里我把变更传导当作一个一等公民来设计。需求条目状态从草稿变更为已确认时事件总线会触发三个动作关联的规格书版本生成一个待更新标记。关联的测试用例状态变为待回归。相关开发任务的描述里追加变更说明并通知任务负责人。这说起来简单落地需要有扎实的数据模型支撑。每条资产都包含标准字段资产ID、类型、版本、状态、来源条目ID、下游条目ID、变更时间、变更人、变更说明。维护好这些字段变更传导才有依据。4.2 复用策略不搞全自动推荐而是人工确认自动引用我之前试过让 Agent 在需求评审时自动推荐相似历史需求结果误报不少。后来把策略调整为双阶段复用。第一阶段是候选召回。需求解析完成后Agent 用语义相似度和关键词匹配双通道把可能与当前需求相关的历史条目找出来形成一个候选列表。第二阶段是关联确认。Agent 不直接把候选塞进当前需求而是生成一份复用建议报告说明每个候选条目的相似点、差异点、建议处理方式直接复用、改造复用、仅作参考。由需求负责人确认后才正式建立关联关系。这个设计看起来效率低了一点但正确率大幅提升。而且当关联关系建立之后后续的变更影响识别才有数据基础。宁可慢一步不能错一次在研发资产复用上这句话特别适用。4.3 测试用例的自动生成与人工修订闭环测试用例是复用和维护负担最重的一块。我的设计是Agent 根据规格书的规则点列表自动生成初始用例每条用例自动标注覆盖的规则编号。生成之后进入人工修订环节测试负责人修改后Agent 对比修改内容把差异回写为规则点补充反向补全规格书里可能缺失的验收标准。这个闭环的价值在于测试用例不再只是验证工具它变成了一种发现规格遗漏的手段。比如一个正常场景下规则点只写了超时关闭订单测试人员在用例里补了一条超时后用户重新支付成功订单重新开启Agent 捕捉到这个差异就会建议规格书补充异常恢复规则。这样测试和需求之间不再是单向消费而是互相增强。我在实际操作中发现闭环设计对提示词和 schema 的要求很高。提示词里必须明确告诉模型你现在生成的每条用例必须关联规格书中的规则编号如果找不到对应规则不要猜测而是标记为未覆盖规则。这个约束一加用例质量提升非常明显。5. 架构落地中最容易翻车的三个环节评估、权限、成本架构图人人会画真正让项目推进不下去的往往是三个隐性环节怎么证明 Agent 产出是好的、怎么控制它能做什么事、以及怎么把成本压到可接受范围。5.1 Agent 评估没有评测体系的 Agent 就是给自己挖坑没有评估体系的 Agent 项目后期一定失控。原因很好理解Agent 的行为空间比传统程序大得多同一个需求模型可能给你三种不同结构的输出没有评测你怎么判断哪个是对的我搭的评估体系分两个层次。第一层是单点评测也叫离线评测。我有一个人工标注的评测集覆盖需求解析、规格生成、用例生成等核心场景大概四百多条。每次升级模型或修改提示词后先跑一遍评测集用结构化字段准确率规则点覆盖率格式合规率这几个指标看效果有没有回退。这个集子的维护很重要每次线上发现的错误案例都要沉淀进来防止同一个坑以后反复踩。第二层是链路评测也叫在线评估。评测的不是单个节点的输出而是端到端的任务完成度。我会给 Agent 布置一个完整的模拟任务比如给一个订单退款需求生成规格书和配套用例并完成复用推荐然后从任务完成率、耗时、人工修正率三个维度打分。这里要提醒一点评测集不要只追求数量要追求场景覆盖的均衡性。我之前做过一个评测集里面正向用例特别多反向用例很少结果模型在异常处理场景的表现一直没被暴露上线后第一轮就有用户在变更影响范围识别上发现 Agent 漏判。后来重新配比了正常场景、边界场景、异常场景的比例问题才暴露出来并被修掉。5.2 权限设计Agent 的能力必须穿透到底层系统研发 Agent 要操作的真实系统包括代码仓库、需求管理平台、测试管理平台。这些系统本身有权限体系Agent 不能绕过它们直接操作。我的做法是Agent 在发起底层调用时必须携带三层身份信息用户身份、项目角色、操作终端。底层系统仍然执行自己的权限校验Agent 只是把用户的真实身份透传过去。这样做有三个好处审计日志能精准定位到人不同项目的同一用户能拿到不同的权限范围Agent 自身的越权行为能被底层系统拦截并记录下来。这个设计在架构图里容易被忽略但它决定 Agent 能不能真正用于企业生产环境。我见过不少 agent 项目POC 阶段一切正常一接入真实系统就被安全团队驳回原因就是权限模型没有想清楚。5.3 成本控制大模型调用是架构里最容易被低估的部分企业研发 Agent 和普通对话机器人不同一个任务的完成往往涉及多次模型调用。以生成一份规格书为例可能包含解析、查重、生成、校验、追问五六个节点每个节点都可能调用一次大模型。如果需求文本又长token 消耗非常可观。我的成本控制策略有三个能不用大模型就不不用大模型。规则能处理的校验、编号生成、字段格式检查一律写死成规则代码不调模型。优先用便宜模型做粗筛贵模型做精修。比如需求查重阶段先用低成本模型做语义粗筛把候选集缩小到五条以内再让更强模型做精细对比。所有模型的输入输出都做结构化压缩。长文档不整段塞给模型而是先抽取关键字段只传必要上下文控制 token 量。这一套策略执行下来单任务成本能比最初的版本降低百分之五十以上。省下来的预算可以用来做更好的评测集、更充分的线上灰度。6. 几个值得单独展开的权衡与取舍6.1 Harness 和 Agent 的分工不是越智能越好是越可控越好不少团队纠结于 Harness 和 Agent 的区别。我的理解是Harness 是一个受控的工作流框架它规定了每个环节的执行顺序、状态转移和异常处理方式每一步做什么都清晰可见Agent 则更强调自主决策模型可以根据情况自己决定下一步调用什么工具。在企业研发场景我最终的倾向是以 Harness 为主Agent 的自主性体现在局部。整个链路是编排好的但链路中的单个节点内部模型有自主能力。比如在需求解析节点模型可以决定用什么方式抽取规则点但在链路层面必须严格遵守解析 - 查重 - 生成 - 校验的顺序。这样既保留了模型的灵活性又让整个流程处于可控、可观测的状态。这个取舍很重要。研发环境里不可控的流程就是灾难。一次错误的自动提交、一个被误改的文档代价都不小。所以宁可牺牲一点端到端全自动的炫技感也要保证每一步都能被人审阅和打断。6.2 Skill 和 Agent 的边界把变化的部分藏在 Skill 内部Skill 和 Agent 的边界划定我参考了微服务架构里的高内聚、低耦合原则。Agent 只关心先干什么、后干什么、什么情况走分支Skill 只关心这一件事怎么高质量完成。Agent 不感知 Skill 内部用的是哪个模型、是不是调了外部 APISkill 也不感知当前任务的上文和下文只处理传入的结构化参数。这个边界带来一个实际的好处当某个环节的模型效果需要优化时我只改对应的 Skill不需要改动编排层。比如测试用例生成质量不达标我调 Skill 内的 prompt、补充它的校验规则就够了整个 Agent 的其他部分不受影响。这种隔离让迭代效率高了很多。6.3 全自动执念的修正人在环路Human-in-the-Loop不是退步是理性设计初期我也追求过需求进来、用例出去全程无人干预的效果。很快发现这不现实也不合理。需求里的业务决策、跨模块冲突、隐性约束模型很难独立判断而且就算模型判断对了团队也需要一个确认环节来建立对系统的信任。所以最终架构里我把每个关键节点都设成了半自动模式Agent 产出初稿 人工确认 反馈回流。人工确认不是简单点一下通过而是可以局部修改修改内容会被 Agent 学习并在下次生成时参考。这个设计等于把每个用户都变成了标注者。系统刚上线时人工介入比率高随着反馈数据积累介入比率逐渐下降。这是我认为企业研发 Agent 最务实的演进路径——没有捷径靠的是闭环数据和持续优化。7. 从 POC 到生产我踩过的几个代表性坑7.1 坑一过度依赖大模型做结构抽取导致输出不稳定最早做需求解析时我直接用大模型从长文本里抽字段结果同一个需求每次跑出来的字段多少不一样。后来改为规则先行文档先按章节和标题层级拆成分段每段再按类型匹配解析模板模板固定下来的字段由代码强制校验只有模板之外的内容才交给模型补充。这一改结构稳定性一下子上来了。这件事给我的教训是大模型的优势是理解语义劣势是精确执行。架构设计里尽量让模型做擅长的事把精确性要求高的部分交给规则代码。7.2 坑二上下文无限制拼接导致效果和成本双输早期版本为了追求生成质量我把历史需求、规格书、相关用例全部塞进上下文结果模型效果反而变差因为无关信息干扰了判断token 成本还暴增。后来采用分阶段取上下文的策略每个 Skill 只取自己需要的最小上下文集比如生成测试用例时只取需求条目、规则点列表和同模块历史用例样例不传完整规格书。效果和成本都明显改善。7.3 坑三没有版本管理的 Agent 配置就是不可复现的实验Agent 的提示词、Skill 逻辑、评测集、模型参数这些配置如果不做版本管理项目跑几个月后你根本不知道当前线上版本是怎么调出来的。我把所有配置纳入代码仓库管理每个版本都有对应的评测记录和上线说明。这样出现问题可以快速回滚对比也方便团队协作迭代。这套配置版本管理和传统软件工程的产物版本管理同等重要。没有它Agent 项目做久了就是一个黑盒没人敢动更没人能继承。8. 演进方向与个人体会整体架构跑通之后我最大的感受是企业研发 Agent 的价值不在于替代某一个岗位而在于把研发链条上的知识资产串起来。单个节点的自动化只是提效真正改变协作方式的是需求、规格、用例、任务之间形成的有机关联。这种关联一旦建立后续的变更评估、质量分析、资源调度都能站在更高维度去做。目前这套架构在团队里最受好评的能力反而不是自动生成规格书而是需求变更后自动告诉我哪些用例要回归、哪些模块要重新评估。因为这是人最耗时、最容易漏的地方Agent 恰好擅长。演进方向上我接下来会重点做两件事。一是把线上运行中积累的修正数据反馈到评测集让评估体系持续逼近真实场景二是探索多 Agent 协作模式下不同角色的分工而不是停留在单 Agent 完成任务的状态。整体思路是架构骨架不变能力和数据的闭环持续转起来让 Agent 在一次次迭代中变得更懂这个团队的研发习惯。