直接做 Agent 工程干了两年多踩遍了循环失控、上下文爆炸、工具调用失灵这些坑之后再回头看现在的 Agent 项目你会发现市面上所有能落地的东西本质上都离不开三个抽象Harness、Loop、Graph。这不是某个框架的发明而是 Agent 工程从玩具走向生产系统时必然长出来的三层骨架。这篇就围绕这三层架构把每一层到底解决什么问题、层与层之间怎么配合、生产环境里这么设计能换来什么全部拆开讲透。别指望看完就能写出生产级 Agent但至少可以让你在下一轮架构评审里不再被这个 Agent 能不能扛并发这个循环会不会死掉这类问题问住。1. 三层架构的整体认知为什么一定是这三层1.1 一个 Agent 项目从零到一最先缺的是什么很多团队刚开始做 Agent第一反应是调用大模型 API写提示词解析返回结果。跑一个 Demo 确实不难一个 Python 脚本加一个简单的 while 循环就够了。但等到要接真实业务、接多个工具、要控成本、要排错的时候麻烦全出来了模型偶尔输出 JSON 带点尾巴工具一次没调成对话历史越塞越长同一个任务跑三次结果都不一样。这时候你才意识到真正的问题不是怎么调大模型而是怎么把一次模型调用包装成一个可控、可观测、可扩展的执行过程。这就是 Harness、Loop、Graph 存在的意义。Harness 管的是 Agent 的外部能力——模型怎么配、工具怎么接、上下文怎么组织、日志怎么埋Loop 管的是 Agent 的内部思维——模型怎么反复推理、工具结果怎么反馈、什么时候该停Graph 管的是 Agent 的整体流——任务怎么拆、分支怎么走、并行怎么合。三层各管一段组合起来才能让一个 Agent 从能跑变成能扛。1.2 分层不是为设计而设计是为了控制不可控性我给非技术朋友打过一个比方Harness 是汽车的驾驶舱按键布局、仪表盘、安全气囊都在这一层Loop 是发动机的运转循环吸气、压缩、做功、排气周而复始Graph 是导航系统哪里拐弯、哪里上高速、哪里有岔路提前规划好。没有导航发动机再强也只是原地轰鸣没有驾驶舱操作再娴熟也无处下手。从这个类比能看出分层的第一性目的把不确定性隔离开。模型本身的输出是概率性的工具的执行结果是不可预测的外部输入是多变的。如果这些不确定性全部搅在一起任何一个小抖动都会导致整个流程崩塌。Harness 把模型和工具的不确定性限制在可控区间Loop 用循环结构把多步推理的不确定性收敛成一个结果Graph 则把业务流程的不确定性变成显式的图结构每一条边、每一个条件判断都可以单独审查和测试。我在实际项目里见过不少反面案例比如把全部工具调用逻辑写在循环里没有 Harness 做统一封装结果三十个工具函数散落在多个文件里互相引用、参数混乱最后改一个工具的入参影响面波及七八个节点。再比如用纯循环做复杂流程想在中间插入一个人工审批节点结果只能靠 if-else 硬编码代码越改越烂。三层架构的约束本质上是在帮你提前划好雷区哪块逻辑归哪层管不要在错误的地方用错误的手段解决问题。2. Harness 层Agent 的驾驶舱与运行环境2.1 Harness 到底封装了什么Harness 这个词在 Agent 工程里的准确理解是一个统管 Agent 运行所需一切外部依赖的容器。它不是某个单一功能而是一个组合体。我自己的项目里Harness 层通常包含五块能力模型配置基础模型选哪个、温度参数怎么设、是否启用流式输出、多模型切换策略比如复杂任务走强模型简单任务走轻模型。这些不应该散落在业务代码里而是统一放在 Harness 配置里做到一处修改、全局生效。工具注册与调度Agent 能调用哪些工具每个工具的入参、出参、权限、调用方式同步/异步、超时和重试策略是什么。有些 Harness 实现还会做工具自动选择根据任务类型把无关工具临时摘掉减少模型误调用的概率。上下文管理系统提示词怎么拼、历史对话怎么截断、检索到的资料怎么注入、大段工具返回结果怎么压缩。这块最容易被低估但也是上下文爆炸问题的多发区域。观测与追踪每轮模型调用的输入输出、每次工具调用的耗时结果、全局的 token 消耗全部以结构化日志的形式记录。没有这一块生产环境里出了问题你连从哪儿排查都不知道。安全与隔离敏感操作前的二次确认、输出内容的合规过滤、工具调用的权限校验。Agent 的自主性越强这一块越重要甚至应该单独做成一个安全层。2.2 工具注册与上下文管理的核心机制工具注册这块我看到的主流做法是声明式注册 运行时校验。你定义一个工具函数标注清楚它的名称、描述、参数结构通常用 JSON SchemaHarness 启动时把它们统一收集起来转成模型可读的 tools 协议格式。这样做有一个明显好处工具元信息和实现代码放在一起不会出现文档里写了一个参数代码里却是另一个的错位问题。上下文管理则要特别说说。很多人以为把历史消息一股脑丢给模型就行等到上下文窗口被占满才开始想办法。我的经验是与其事后压缩不如事前做分段注入——系统提示词单独占一个 segment业务上下文占一个 segment工具调用历史单独管理这样既方便按权重做截断也方便针对不同 segment 设置不同的保留策略。早期我最常犯的错误就是把所有内容拼成一段超长文本结果模型的理解力明显下降后来改成结构化分段之后长对话场景的效果立刻改善。提示Harness 层最容易犯的错是过度封装。我见过有的团队把模型调用包了五六层抽象为了支持未来可能的扩展结果改一个小小的提示词要翻四个文件。Harness 不需要把每个细节都封装起来把边界定清楚把频繁变化的东西收敛到配置里就够了。2.3 Harness 与 Agent 框架的关系市面上的 Agent 框架比如 LangChain、LlamaIndex、Pydantic AI其实都内置了部分 Harness 能力。但如果只依赖框架自带的那一套到生产阶段通常会吃力的。框架可以帮你把基础功能搭好但真正的 Harness 一定要基于你自己的业务场景去做定制你的工具链是特有的你的上下文格式是特有的你的安全机制是特有的这些是一套通用框架给不了你的。我现在的项目里Harness 层是一组接口加一个配置中心Agent 主体逻辑不感知模型厂商和工具实现的细节只管面向接口编程。这样做的代价是前期要多写一些胶水代码但收益在于后续无论是换模型、加工具还是调策略都只是配置变化不用动业务代码。3. Loop 层Agent 的思维循环与执行引擎3.1 从一次调用到多轮循环Agent 的本质特征单次的大模型调用不叫 Agent只能叫增强型问答。Agent 和普通 AI 服务的本质区别在于多轮自主决策——模型观察当前状态决定要调用什么工具拿到工具结果后重新推理再决定下一步动作直到达成目标或到达终止条件。这个观察—推理—行动—再观察的过程就是 Loop 层要管的核心。我在团队内部画过一张示意图一个标准的 Agent Loop 包含四个阶段观察收集当前任务目标、历史对话、工具返回结果、环境状态形成模型可读的上下文。推理模型基于当前上下文思考输出下一步意图可能是继续调用某个工具也可能是给出最终答案。行动解析模型的工具调用指令对参数做校验执行真实工具调用获取结果。更新把工具结果写回上下文循环进入下一轮直到满足终止条件。这个循环看起来简单实际工程里每个环节都有数不清的细节。只说一个最常见的坑模型第一次返回的工具参数里某个字段格式和工具要求的不一致比如它给了一个数字字符串而工具要用整数。如果你在行动阶段不做类型转换和校验工具直接抛错循环就会走进异常分支。别指望模型每次都输出完全规范的 JSON生产级的 Loop 必须在行动之前加一层严格的参数解析和校验甚至要具备根据报错信息自动修正参数重试的能力。3.2 循环收敛让 Agent 知道什么时候该停Loop 层比循环本身更重要的是循环的终止条件。这一块如果不设计好Agent 就会陷入两个极端要么过早停止任务没完成就给出了半吊子答案要么无限循环在几个工具之间反复打转token 烧完才被熔断。我常用的终止条件有四种实际项目中通常会组合使用任务完成判定模型输出明确表示已完成且包含了最终答案。判定词可以是FINAL_ANSWER任务完成等约定标记也可以让模型输出结构化结果由 Harness 层校验必填字段。最大轮次限制给循环设上限比如最多 15 轮工具调用。这是一个兜底保护防止任何逻辑漏洞导致无限循环。生产环境里这个限制一定要有而且要根据业务场景谨慎调整太小会误杀正常任务太大则失去保护意义。成本预算限制跟踪累计 token 消耗超过预算后强制终止进入降级流程比如转人工、转轻量模型。尤其在模型费用敏感的场景这个比最大轮次更有效。人工介入关键时刻让真人确认确认通过才继续执行。这是目前所有生产级 Agent 都应该保留的一个兜底。我在一个表单自动填写项目里遇到过典型的循环问题Agent 在一次填写失败后反复尝试用同样的方式重新提交连续循环了八次每次都在同一个校验错误上失败。原因是提示词里没有约束当遇到明确的业务规则校验失败时应该停止并报告而只有如果失败就重试。后来我在系统提示词里加了一条如果同一个错误连续出现两次停止尝试并认为任务失败输出失败原因再配合最大轮次限制这个问题才算根治。3.3 Loop 的错误处理与自愈机制Loop 的另一个关键设计是错误后的自愈路径。工具调用大概率会失败网络超时、第三方接口限流、参数不合法、数据格式变化。如果只做简单重试很多问题会重复发生。正确的做法是区分错误类型临时性错误超时、限流、瞬时的网络抖动自动重试采用指数退避策略重试次数限制在 2-3 次。参数性错误工具入参不合法、缺少必要字段、类型不匹配不重试而是把详细的报错信息喂回给模型让模型基于报错修改参数后重新调用。业务性错误业务规则校验失败、数据冲突、权限不足立即终止该路径向用户返回明确的失败原因不要盲目重试。这个分类在代码里可以做成一个统一的异常处理中间件挂在工具调用的外层。我见过最愚蠢的做法是所有的错误一视同仁地重试三次结果一个参数性错误被重试三次白白浪费 token 和时间还把日志刷得没法看。实操心得Loop 层一定要做思考痕迹的留存。每一轮模型推理时把它的思考过程、工具调用决策、结果摘要都记录下来。这不仅是审计需要更是调试 Agent 的核心抓手。很多 Agent 表现异常的根因不看思考痕迹根本定位不到。4. Graph 层从线性循环到可控的工作流编排4.1 为什么纯 Loop 撑不起复杂业务先澄清一个容易混淆的概念Loop 是单次任务内部的推理循环Graph 是多个任务步骤之间的编排结构。一个复杂业务比如调研竞品 → 生成对比报告 → 发送到内部群单个 Loop 搞不定因为步骤之间有关联和条件分支需要一种更高层的组织方式。如果硬用纯 Loop 做多步骤任务会面临三个问题状态难以管理每一步产生的结果散落在上下文里下一步怎么引用全靠模型自觉分支逻辑不清晰条件判断只能写在提示词里模型可能判断错还没有办法人工干预步骤不可复用流程一多每一条路径都要重新写一遍循环代码大量重复。Graph 层解决的就是这些问题。它把业务流程抽象成一个有向图节点表示一个具体的执行步骤可能是一个子任务、一个工具调用、一个判断条件边表示执行顺序和依赖关系。图上可以挂条件分支、并行节点、循环子图整条流程的形状是显式的可以被测试、被监控、被人为干预。4.2 Graph 的核心元素节点、边与状态要理解 Graph 层至少要搞清楚三个核心概念。节点Node一个节点就是一次执行单元它可以是调用一个子 Agent内部又有自己的 Loop可以是调用一个工具函数也可以是一个纯逻辑节点比如条件判断、数据清洗。节点之间通过边连接每个节点接收上游传入的数据处理后传给下游。边Edge边表达流向。最简单的是顺序边上一个节点完成下一个节点开始。复杂一点的是条件边——根据上游节点输出的内容决定走哪个分支。再复杂的是循环边某一部分流程可以被重复执行直到满足退出条件。状态State这是 Graph 与 Loop 最大的不同。Loop 的上下文是隐式的、向模型暴露的连续文本Graph 的状态是显式的、由你定义的数据结构。比如一个报告生成流程的 State 可以包含research_results、draft_content、review_comments、final_version等字段每个节点只读写自己需要的字段。这样状态流转完全可控不依赖模型的记忆。我最初从纯 Loop 迁到 Graph 时最大的不习惯就是状态设计。以前让模型记住上一步的结论靠的是把结论写进对话历史模型通常能记住但偶尔会记混。后来用 Graph 显式地把关键结果写入 State节点之间传参不走上下文准确率立刻上来了而且每一步的数据都能精确定位。4.3 分支、并行与人工节点的生产意义Graph 真正的工程价值体现在三种特殊节点的设计上。分支节点代码里就是 if 条件但 Agent 工程里常常让模型来决定条件。比如一个客服 Agent先判断用户意图是退换货、咨询还是投诉然后走不同的处理子流程。这个意图分类可以是一个独立的 LLM 节点输出一个结构化的分类标签Graph 根据标签路由到对应分支。这样做比在提示词里让模型自己看着办要稳定得多——意图判断的准确率可以被单独测评和优化。并行节点有些步骤彼此独立比如同时查三个不同的数据库或者同时调用多个外部 APIGraph 支持把它们并排列出所有节点完成后统一汇总。在提效这件事上并行往往比优化单个模型的推理速度更能立竿见影。人工审批节点高风险的业务操作发送对客邮件、执行转账、删除数据必须有人工确认。Graph 里把这些操作设计成一个暂停节点运行到此处时流程暂停等待人工通过 API 或消息系统确认后才继续。这在纯 Loop 架构里实现起来极其痛苦在 Graph 里则只是节点类型的一种。4.4 用 Graph 控制复杂度的经验Graph 也不是越多越好。我见过把 Graph 用到极致的团队一张体系图塞了几百个节点几乎无法维护加一个新功能要在一个巨型图里找半天位置。我的经验是遵循漏斗式分层顶层保持简洁每个大步骤是一个子图细节在子图里展开。主图最好控制在 5-8 个节点给一个非技术的产品经理也能看懂真正复杂的逻辑下沉到子图里。另一个经验是图结构和代码描述要保持一致。有些框架允许你用代码声明式地构建图但生成的图结构很难直观预览有些框架提供可视化界面。不管用哪种一定要保证团队对当前线上的流程长什么样有共识否则改了一个节点连带的边界条件没人能说清楚。5. 生产实践三层架构如何在一个真实项目里协作5.1 一个典型的智能资料整理 Agent架构拆解用一个我自己做过的项目来串起三层架构。背景是企业内部需要定期整理外部竞品动态收集公开信息、过滤噪音、按模版输出周报。任务不算特别复杂但流程长、环节多、还有人工审核纯 Loop 绝对搞不定。开始设计时我把它拆成了四个主节点对应一个 Graph资料抓取 → 内容清洗与去重 → 分析师子 Agent 摘要 → 人工审核并发送。主图大概 6 个节点每个节点内部再有子图或者内置一个 Loop。Graph 的顶层入口节点接收任务参数比如竞品名单和时间范围、抓取节点调用各类检索工具并把原始结果写入 State 的raw_docs字段、清洗节点纯代码逻辑不经过模型做格式规范化、去重、摘要节点一个内置 Loop 的子 Agent加载模板并生成摘要初稿、审核节点挂起等待人工确认、发送节点确认通过后发送并归档。这个架构里Harness 层负责所有外部工具的接入搜索 API、网页抓取工具、企业内部分发接口以及统一的两套模型配置强模型用于摘要生成轻模型用于意图分类上下文策略也在这里定义。Loop 层主要活在该子 Agent 内部摘要 Agent 需要先读所有原始资料然后生成提纲再根据提纲逐段撰写中间可能要多次调整措辞这个多次迭代就是 Loop 的工作。Graph 层承担整体的流程编排、条件分支和人工审核中断。5.2 状态传递与数据流设计这个项目里State 的设计是最关键的部分。我定义了大约八个字段task_config、raw_docs、cleaned_docs、summary_drafts、review_status、final_content、dispatch_log、error_log。每个节点只负责读写和自己相关的字段上下游之间不直接传对象而是通过 State 读写接口完成。选择这要样的设计是出于一个特别实际的考虑便于并行和重放。并行节点各自写入不同的字段互不冲突执行失败时能精确定位到是哪个字段没有赋值哪个节点没跑完。调试时还能把一个 State 快照导出在测试环境里重放整个流程这个能力在生产排错时极其好用。另一个实际收益是上下文隔离。顶级 Graph 的各个节点内部有各自的 Loop这些 Loop 的上下文相互隔离不会出现上一个节点的历史对话污染下一个节点的情况。以前用单一大循环做整条流程时问题层出不穷摘要 Agent 会记住上次检索的噪音信息或者把上一步的中间结果当成最终结论。Graph 的隔离机制把这类问题从根上解决了。5.3 可观测性与日志体系怎么搭三层架构的每一层都要对应到可观测性设计。我的日志体系分成三级和三层架构对应Harness 层记录每一次模型 API 调用的耗时、token 消耗、温度参数Loop 层记录每一轮的推理摘要、调用的工具、返回的结果摘要、重试原因Graph 层记录每个节点的开始/结束时间、状态快照、分支走向、审批动作。生产环境里真正会被逼疯的是两个问题一个是模型为什么做了这个决策一个是这个流程为什么会卡住。三级日志体系基本能把这两个问题回答清楚。我还会在 State 变化的关键节点输出 diff 日志显式标出哪个字段被哪个节点改了这在实际排错中省了太多时间。5.4 并发能力与资源控制标题里相关的热词还有AI Agent 怎么扛并发这里展开说一下三层架构对并发的支撑。三个层各自要做的并发处理完全不同。Harness 层的并发重点是 API 限流与队列管理。我通常会做一个按任务维度分组的调度器控制同一时刻发往模型供应商的请求数避免触发限流。可以做一个简单的信号量控制import asyncio from contextlib import asynccontextmanager class ModelRateLimiter: def __init__(self, max_parallel8): self._sem asyncio.Semaphore(max_parallel) asynccontextmanager async def acquire(self): async with self._sem: yield这个限流器在 Harness 层的模型调用接口前统一挂上不管上游有多少任务并发进来实际打到模型接口的并发都控制在安全水位。核心逻辑就是吞吐量优先在用户侧排队不要让供应商把你封了。Loop 层的并发重点是工具调用的超时和并发。一个 Loop 内部可能同时调用多个工具用asyncio.gather做并行但每个调用都要设置超时否则一个慢工具会拖死整个循环。Graph 层的并发重点是节点间的依赖关系。相互独立的节点天然可并行Graph 引擎要能识别这类依赖并自动调度。如果每张图都是串行跑那并行节点的设计就白做了。6. 常见问题与排查经验实录6.1 Agent 陷入循环出不来怎么排查和根治现象Agent 在同一个工具上来回调用每次参数几乎相同结果也一样但就是不停。排查步骤第一步看 Loop 层日志里的思考痕迹确认它是真的没有意识到重复还是意识到了但提示词没给它该停的指令。第二步看最大轮次限制是否生效如果生效了为什么没有走降级分支。第三步看工具返回的结果是否每次一致如果工具结果是相同报错说明是参数修复失败的问题。根治方案在系统提示词加入相同错误不得连续重试超过一次这类护栏对工具调用结果做哈希去重检测到连续相同行为时强制跳出提高最大轮次数或者引入成本熔断。我建议先做工具结果去重这个在代码层面就能搞定不需要依赖模型的自觉性。6.2 上下文爆炸与记忆丢失现象任务进行到中后段模型开始忘记早期的重要信息或者回答质量明显下降。根因上下文管理策略太简单把整个过程产生的所有内容都堆到对话历史里窗口被占满后早期的关键信息被截断或者模型注意力被噪音分散。解法Harness 层做按 segment 的结构化上下文管理关键信息任务目标、用户约束、中间结论放进持久区普通对话内容放进滚动区并限制保留轮数定期用一个小模型做关键信息抽取把长对话压缩成结构化摘要写入上下文。这个技巧我用过很多次效果立竿见影唯一的代价是每次摘要多一点 token 开销但比起上下文爆炸带来的失败和重试成本这点开销完全可以接受。6.3 工具调用参数总是出错现象模型生成工具调用参数经常不合法字符串、数字类型混淆必填字段缺失枚举值超出范围。根因工具描述和参数 Schema 不够详细或者模型本身在长上下文下的工具调用精度下降。有时候问题出在 Harness 层没做好参数校验错误信息没有回传给模型。解法把工具参数的 JSON Schema 写细每个字段的枚举值、格式、示例都写清楚别指望模型看到string类型就自动会传对参数校验放在工具执行前校验失败时把结构化的错误信息返回给模型并给一句根据错误信息修改参数后重新调用的指令实在频繁出错的场景可以在工具调用与执行之间加一个小型参数修复专用模型用轻量模型专门做参数修正成本很低准确率提升明显。6.4 多任务并发时状态互相污染现象两个任务同时跑结果一个任务的中间结果写进了另一个任务的 State或者日志里面出现了另一个任务的上下文。根因对每个 Agent 实例的隔离做得不彻底。Loop 内部使用了一些全局变量或者 State 被设计成单例/类级别的对象并发跑的时候就互相踩。解法状态对象必须按一次运行一个实例每次任务分配独立的 State 对象和对应的日志上下文 IDtrace ID工具调用队列也要按实例隔离不要在多个 Agent 实例之间共用同一个工具执行器把并发测试写进 CI每次改动都跑一遍双任务并发用例。注意这里的并发指的是应用层同一进程内多任务并发不要和模型供应商侧的高并发混淆。很多团队在设计时没在意实例隔离生产环境第一次上并发压力就翻车提前在设计上就把一个任务一个 State 实例的原则钉死后续能避免大量事故。7. 三层架构与工程框架的选型建议7.1 源码还是框架各有利弊现在聊到落地免不了要说框架。市面上的 LangGraph、Pydantic AI、自研 Graph 引擎各有取舍。LangGraph这类重框架最大的优势是图引擎成熟状态管理、断点恢复、人机交互都有现成的方案社区资料也多。劣势是抽象层厚出了问题你要翻框架源码才能搞明白调试成本高升级版本还可能破坏旧行为。Pydantic AI这类轻框架胜在模型定义清晰、类型安全好适合 Hint 面。但 Graph 能力相对简单复杂流程还得自己叠一层。自研是很多团队走过弯路之后的选择。我的观点是如果团队有比较强的工程能力且 Agent 的业务逻辑是非标准化的自研一个轻量引擎并没有想象中那么贵——核心就是状态管理、节点调度、日志追踪、人工介入大约一至两周能搭出一个够用的骨架。自研的优势是完全掌控修改边界没有被框架升级绑架的风险。但如果你只是想快速验证业务价值建议直接用成熟框架别一上来就自研前期可以省下大量时间。我在项目里的做法是框架做底座自研做外壳Graph 引擎用选型好的框架Harness 和业务编排完全自研这两层属于业务高度相关的地方框架的通用抽象帮不上太多忙。7.2 对团队能力的要求三层架构对团队的最小要求是每个人都要能区分这三层在项目里各自负责什么。Harness 层需要熟悉模型 API 和工具链Loop 层需要理解推理循环和异常处理Graph 层需要会做流程建模和状态设计。一个人全干也不是不行但很容易出现某一层特别强、其他两层薄弱的不均衡状态。在我见过的团队里最常出现的问题是 Graph 层变成摆设——图标得天花乱坠实际执行还是靠写死代码拼出来的。这种伪 Graph架构往往比真 Graph 更脆弱因为图结构已经名存实亡但没有人发现。如果团队刚起步我的建议是不要急着上完整的三层架构。先用一个最简单的 Loop模型加一个工具循环跑通一个端到端场景理解 Agent 的执行过程然后引入 Harness把工具和上下文管理规范化最后等出现了多步骤、分支、人工介入这类需求时再引入 Graph。循序渐进比一开始就上一个复杂框架然后陷入抽象陷阱要有效得多。7.3 三层架构的演进方向聊点扩展的方向。多层架构不是终点用 Harness 和 Graph 搭建起的 Agent 工程底座天然有一个演进路径Harness 层的下一步是强化自省能力——让系统自动评估上下文质量主动压缩或补充信息而不是等模型犯错后再修Loop 层的下一步是多 Agent 协同循环——几个 Loop 并行跑、互相校验结果类似生成—批评—修改的对抗模式Graph 层的下一步是动态组装——不再固定一张图而是让模型根据任务现场动态生成图结构再交给执行引擎去跑。这条路很难但现在越来越多的框架开始探索了。回到实际操作我个人最大的体会是这套三层架构不是哪个框架、哪篇论文发明的教条而是从一次次线上事故里长出来的实践约束。它帮助团队在模型层、工具层、流程层之间划出清晰的边界让排错有了方向让测试有了粒度。理解它、掌握它再去评价一个 Agent 项目的工程质量你的判断会精准很多。
技术路径与产业应用分析)
