Agent 测试系统的意义与"通用 DAG"辨析

把 AI 大模型当做一个人：对人的训练都可以抽象成"给他知识、让他工作"。那么做 Agent 测试系统有什么意义？直接做一个通用 DAG 是不是就能完成任何工作？AI 自动生成 DAG 之后是不是就通用了？Agent 开发者会失业吗？本文记录这组讨论。

一、测试系统的意义：考核 ≠ 培训

"给人知识、让他工作"这个抽象漏掉了一半：人除了培训，还需要考试、试用期、绩效考核、质检。原因是人的能力是不可直接观测的黑盒——不能看一个人的大脑就知道他会不会犯错，只能通过"让他做题、看他产出"来度量。

大模型把这个特点放大了：

非确定性：同一个人、同一道题，昨天答对今天可能答错（temperature、上下文扰动）。人的波动小，模型的波动大得多。
版本漂移：人毕业后再培训的频率很低；模型 provider 悄悄升级一次，整个 agent 的行为可能就变了。
能力边界未知：人可以问"你学过这个吗"，模型永远是"自信地回答"，包括它不会的东西。

所以测试系统（eval 体系）的意义不是"让它工作"，而是建立信任度量：上线前知道能力边界在哪，上线后发现回归，迭代时证明新 prompt 真的更好而不是碰巧更好。没有 eval 的 agent 迭代，本质上是在碰运气。

二、通用 DAG 能完成任何工作吗？

不能。DAG 表达的是已知的流程，而 agent 要解决的恰恰是流程事先未知的任务。

如果一个任务的步骤可以被人穷举并写死成 DAG，那这个任务本来就不需要"智能"，传统的程序/工作流引擎早就解决了。把 LLM 塞进 DAG 节点，只是给确定性流程加了几个会犯错的节点，不确定性并没有消失。
真实任务（修一个没见过的 bug、调研一个陌生领域）的关键步骤是"走到一半才知道下一步干什么"。这需要动态规划（ReAct / planner），DAG 的静态拓扑表达不了"根据观察结果决定后续分支数量和内容"。

所以 DAG 和 agent 不是替代关系，是分工：流程可枚举的部分用 DAG（可预测、可审计），开放部分用 agent。真正难的也不是编排拓扑，而是每个节点里的上下文工程、工具设计、错误恢复——换一个 DAG 框架并不能省掉这些。

三、AI 自动生成 DAG，是不是就通用了？

"根据上下文生成下一步任务"和"AI 自动生成 DAG"这两条路线都已经存在，并且收敛成了 agent 本身：

动态生成下一步 = ReAct 循环，最原教旨的 agent 定义：观察 → 想一步 → 做一步 → 再观察。
自动生成 DAG = Planner-Executor 架构（Plan-and-Execute、LLMCompiler 这类）：先让模型把计划展开成 DAG 再执行，走偏了重新规划。

所以结论不是"通用 DAG 取代 agent"，而是 DAG 动态化之后收敛成了 agent。编排层的形态之争是伪命题，最后大家都是"模型在某个循环里决定下一步"。

瓶颈不在架构，在三个更硬的地方：

错误沿计划放大。静态 DAG 错一个节点，影响是局部的；自动生成的计划第一步规划错了，后面整条链都在错误前提上执行。规划自动化程度越高，验证层（verifier）越关键——而验证本身是难题：代码任务好验证（跑测试就行），"写一份市场分析"谁来判断好坏？这就是 generator-verifier gap：模型生成能力普遍强于自我验证能力。
可审计性与安全边界。人写的 DAG 是白名单：能调什么工具、花多少钱、访问什么数据，一眼可见。模型现场生成的流程是黑名单逻辑——得防它做出任何没预料到的动作。金融、运维这类场景不敢用纯动态规划，不是技术不够，是治理不允许。
状态与上下文。长任务跑到一半，上下文里该保留什么、丢弃什么，计划怎么表示成模型能持续操作的中间状态——比"生成下一步"本身难得多，目前也没有通用解。

工程实践因此收敛到混合架构：高层骨架由人或模板定死（可控、可审计），骨架内部的局部步骤允许模型动态决策（灵活性），外面再套一层 checkpoint + verifier + eval。纯动态 agent 目前只在"可验证、可回滚、失败代价低"的场景（写代码、查资料）真正好用。

四、Agent 开发者会失业吗？

不会消失，但工作内容在迁移。历史上每次抽象层级提升（汇编 → 高级语言 → 框架 → 低代码），消失的都是"重复搬运"的部分，留下的是离问题本质更近的部分：

在贬值的：手写 prompt 雕花、堆 if-else 补模型短板、自己造编排轮子。
在升值的：上下文工程（给模型什么信息比怎么问重要得多）、工具/API 设计、评估体系、护栏与成本控制、把领域知识结构化喂给 agent 的能力。

一个证据：模型越强，eval 越重要而不是越不重要。弱模型不行就肉眼可见；强模型"看起来都行"，只有系统化的测试才能区分 90 分和 95 分——而生产环境里 90 分往往就是不可用。

五、结论

知识和工作只是 agent 的"供给端"，测试是"验收端"；DAG 只能编排已知，agent 的价值在于探索未知；而"AI 自动生成计划"没有让测试系统变得多余，反而让它从"验收端"变成了运行时的一部分（verifier、checkpoint、在线 eval）。规划质量怎么度量、verifier 靠不靠谱、回归怎么发现——每一步都指向测试和评估体系，这正是 Agent 工程化里壁垒最深的部分之一。

六、延伸：为什么不直接做通用智能体平台，把测试当成一种任务？

"测试只是一种任务，DAG 流也用通用 AI 生成"这个方案的问题，在于测试和其他任务的目标函数根本不同。

1. 测试任务和普通任务的区别

普通 agent 任务的目标是产出一个工件：写一段代码、生成一份报告，成功 = 工件存在且质量不错。测试的目标是对另一个系统建立信心（或发现风险），这带来三个通用平台天然缺失的东西：

Oracle 问题：测试的核心不是"执行步骤"，而是"判定对错的标准"。通用 agent 能点完一个登录流程，但"返回 200 但权限校验没生效"算不算 bug？构造 oracle 需要领域知识，通用平台没有内置这个能力。
环境生命周期：测试要准备被测系统、造数据、保证隔离、执行后清理。这是一整套领域基础设施，不是"一个任务步骤"。
可重复性：测试结果必须可重放、可审计，否则"昨天过了今天没过"无法定位是被测系统变了还是 agent 抽风。这对动态生成的流程是额外的硬约束。

2. "DAG 由通用 AI 现场生成"在测试场景反而没必要

测试恰恰是流程可枚举程度高的领域：需求分析 → 用例设计 → 环境准备 → 执行 → 判定 → 报告，这个骨架几十年没变过。所以：

测试是"混合架构"的最佳落地场景——骨架用 DAG 定死（可控、可审计），节点内部用 AI（用例生成、断言编写、失败归因），正好发挥两边所长。
"每次让通用 AI 现场生成 DAG"在这里是负资产：多花 token、每次流程不一样（无法审计、无法对比历史）、重新犯已经犯过的错。测试流程模板是应该沉淀的领域资产，不是每次重算的一次性产物。

3. 测试智能体平台的真正意义：数据飞轮和信任链

通用平台可以"做测试这个任务"，但它没有动力也没有位置去积累这些东西：

领域资产飞轮：用例库、历史缺陷模式、flaky test 名单、"哪类需求最容易漏测"、某系统的常见误报……每执行一次测试，平台就变聪明一点。通用 agent 平台里这些数据散落在无数次会话中，无法结构化沉淀。平台的自进化（见 Agent 测试平台的自进化方案）需要领域化的记忆结构，通用记忆做不到。
信任链：测试的产出是给人（QA、开发、发布决策会）做依据的。"AI 说测试通过了"要能被信任，需要专门的证据链设计：执行录屏、断言明细、失败时的最小复现。通用 agent 的报告是"我做了什么"，测试平台的报告是"你为什么应该信"。
成本与准确率：针对测试优化的 prompt、工具集、上下文组织，在同样模型下成本和准确率都优于通用 agent——就像有 Cursor 之后没人拿 ChatGPT 网页版写代码。

4. 结论

通用 vs 专用不是二选一：测试智能体平台应该建在通用 agent 底座之上，但领域层必须专用。通用底座解决模型调用、工具协议、编排；专用层解决 oracle 构造、环境管理、流程模板、资产沉淀、证据链。

一句话：通用平台能让 AI"做一次测试"，测试智能体平台让一个组织"持续拥有越来越强的测试能力"。前者是消费 AI 能力，后者是把 AI 能力变成组织资产。