干开发这些年我听过最多的说法是TDD 真的正确但真的难坚持。难在哪难在“先写测试”是对人性的考验——看着红灯亮起来人会本能地怀疑方向是不是错了难在写测试本身也有成本你还没见到任何功能就得先憋出一堆断言更难在需求一变动测试比代码先崩重构的勇气直接归零。这两年 AI 智能体把局面改变了。你不再需要自己一个人撑着“先测试、后功能”的纪律而是可以把写测试、跑测试、看失败、修实现这一整条链路交给一个能读懂结果并不断迭代的 Agent 去跑。人退到定义需求和验收结果的位置让 Agent 在测试循环里反复“碰壁—调整—再碰壁—再调整”。这个概念叫“AI 智能体赋能 TDD”很多人也叫它自动化测试驱动开发的新范式。这篇文章我会把为什么需要 Agent、闭环怎么设计、实际跑通一个模块、再到踩坑排查按我自己的实践顺序讲透。1. TDD 的旧痛点与新变量智能体为什么能补位1.1 传统 TDD 的三大硬伤传统 TDD 的流程大家不陌生根据需求先写一个失败测试然后写最小实现让测试变绿最后重构。原理看上去完美落到日常开发里却有三大硬伤。第一是“测试前置”对人的状态要求极高。写测试本身比写实现更抽象。实现代码可以先堆糙一点再慢慢打磨测试代码却必须在功能不存在时就描述出“功能应该是什么”。人一旦疲劳、压力大第一反应就是跳步先把功能写出来测试以后再说。这个“以后”往往就是永远。第二是红灯阶段的决策成本被低估。想写出一个刚好不过头、又能真正驱动设计的失败测试不是随便写个断言就行。你得先想清楚输入输出域、边界条件、异常路径。这个过程特别消耗意志力新手容易卡死在第一步老手也经常把复杂业务模块的 TDD 一拖再拖。第三是重构阶段缺少安全感。测试能降低重构恐惧但这个信念依赖“测试足够充分”。如果测试是后来补的覆盖率空有数字、断言却全是假阳性重构照样会漏坏。人对这套护栏不信任自然就不敢动代码。这三个痛点本质上都是同一个问题TDD 对人类有很高的认知代价。而“认知代价”恰好是大模型和自动化工具擅长替代的东西。1.2 AI Agent 与“AI 辅助编程”的本质区别先厘清概念。我讲的不是 IDE 里那种自动补全也不是“帮我生成一个函数”的问答式助手。AI 智能体和它们的本质区别在于有没有“执行—反馈—修正”的闭环。普通的编码助手给一段代码就结束了它不知道这段代码能不能编译、测试是不是真跑了。Agent 不一样它可以拿到执行结果、失败断言、堆栈信息再基于这些结果做下一轮调整。Agent 不是生成器而是一个具备执行反馈的循环体。这个差异对 TDD 极其关键。TDD 的整个价值在于反馈回路质量测试红得越快、失败信息越准下一步实现就越有方向。Agent 天然适合这个回路因为它可以在每一轮运行测试把失败结果重新注入上下文如此反复直到目标达成。我在一个演示项目上跑过的体感是Agent 只要把“跑一次 pytest 当成常态动作”它的行为模式就非常接近一个较真的 TDD 践行者——先写测试、跑出红灯、再做最小实现、等灯变绿然后才进入重构。1.3 哪些场景适合让 Agent 上岗不是所有项目都适合立刻把 Agent 拉进 TDD 流程。我大致把场景分成三类。第一类接口、函数、纯逻辑模块这类非常适合。比如工具函数、价格计算、校验规则、协议解析器输入输出边界清晰失败信息明确Agent 能稳定发挥。下面实操演示就选这类。第二类大数据流、复杂状态机、跨系统集成这类需要谨慎。不是说 Agent 做不了而是失败信息的解释成本太高。Agent 判断出错时容易做“猜测性修补”反而把代码搞乱。这类场景我建议让 Agent 做局部模块人负责整体编排。第三类老代码改造。这类目前最容易被高估。老代码往往缺少测试基座Agent 很难凭空生成可靠的行为测试。更务实的用法是先让 Agent 给老代码补一批“行为快照测试”把当前行为固化成基线再在这个基础上做重构。少了这一步Agent 面对历史资源时表现会明显下降。1.4 从“人盯人”到“机制自治”的范式变化“新范式”三个字不是夸张。传统 TDD 靠的是人的自律每天告诉自己先写测试、不要跳过红灯、重构要克制。这套事情坚持一两天可以坚持几个月就会被打回原形。AI Agent 带来的变化是“机制自治”测试红线由 Agent 生成失败反馈由 Agent 收集实现代码由 Agent 迭代验证结果由命令行退出码决定。纪律被写进了执行流程而不是凭人的意志力维持。这不是说人没用了。相反人的角色更向“定义者”和“验收者”倾斜需求边界由人定测试强度由人定最终 review 由人做。说到底Agent 解决的是执行层疲劳人解决的是目标和判断问题。两者叠加TDD 才第一次有了“自动化”的完整含义。2. “红-绿-重构”的 Agent 闭环设计2.1 把循环翻译成 Agent 的工作流Agent 要处理 TDD最顺手的结构是把它变成三步循环生成红测试Agent 根据需求描述先写测试文件运行测试得到失败结果。这个失败必须来自“产品代码还没实现”否则测试就没有驱动力。读取失败写实现拿到失败断言和堆栈后让 Agent 补上最小实现再运行同一组测试直到从红变绿。重构并回归让 Agent 做小步重构比如提取函数、变量重命名每次改动后都全量跑一遍测试保证绿灯不灭。这个循环看似简单真正难点在“怎么看失败结果”。新手带偏的常见原因是“测试写错了却以为代码错”Agent 也会出现同样误判。它没有常识判断力必须通过机制让它明确区分“是测试期望有误还是实现行为有误”。我的解法是给闭环加入一个中间步骤Agent 拿到失败结果后先输出一段“失败归因”说明它认为哪一侧出了问题再决定改测试还是改实现。这个归因不一定对但至少会把判断过程暴露出来由我在第二次迭代时检查。2.2 三个决定成败的设计决策第一个决策叫“上下文边界”。不要让 Agent 直接读整个仓库。我吃过亏在指令里写“看一遍项目里所有文件再动手”Agent 会生成一个气势磅礴但完全跑不通的方案。合理的做法是只给模块级白名单例如只给discount.py、test_discount.py、requirements.txt这几个文件操作权限其他文件只读不可改。上下文边界越窄Agent 越聚焦幻觉越少。第二个决策叫“失败信息回传”。测试失败日志要结构化。我习惯把工作流封装成运行测试 - 拿到退出码和失败列表 - 将每条失败信息截断到关键行比如断言行和前 20 行堆栈- 喂回 Agent。如果一股脑把几千行日志丢给它它会被无关输出带偏或者误判“这个测试本身有问题”。信息不干净等于噪音。第三个决策叫“置信度闸门”。如果 Agent 没完没了地重试会变成一个烧钱机器。所以给循环设了上限最多迭代 N 轮如果 N 轮后仍有红灯就停下把当前测试和实现差异交给人工判断。没有这个闸门你很难分辨 Agent 是在认真调试还是在幻觉式打补丁。2.3 角色职责分割谁来当验证官有一点很多人容易忽略不要让 Agent 既写测试又验证自己的测试。我的经验是把验证动作交给固定脚本由脚本在写完测试或实现后立刻运行。Agent 只负责“修改文件”“运行测试”这个动作必须从工具调用里独立出来。听上去是小事但很关键。不做这个分离你会看到 Agent 在回答里自称“已经通过测试”实际根本没跑。为了治它我会在工作流里写死指令只要改完文件必须执行测试命令并把输出贴回。裁判权永远在命令行的退出码手里不在 Agent 的自我陈述里。2.4 终止条件也要写进任务卡很多 Agent 驱动 TDD 为什么会失控因为它没有明确的结束信号。我把“完成标准”写进任务卡一般包含三条指定测试命令的退出码为 0所有目标模块的功能点至少有一个正向断言和一个反向断言没有修改白名单以外的文件。这三条缺一不可。退出码为 0 是最低标准但光有绿可能覆盖不足只有断言没有退出码说明 Agent 可能根本没跑白名单约束则是安全网防止它顺手改了无关文件。把这些标准前置写清楚 Agent 才有机会在正确路径上停稳。3. 实操让 Agent 驱动一个模拟模块的 TDD3.1 准备一个最小战场为了把概念讲明白我拿一个模拟项目里的折扣计算模块做演示。模块接口很简单有compute_discount(price, discount_code)函数传入原价和优惠码返回折扣后的价格非法优惠码抛ValueError金额保留到两位小数。项目结构如下sim_project_x/ ├── discount.py # 目标实现 ├── test_discount.py # 测试文件 └── agent_tasks.md # 给 Agent 的任务卡我给 Agent 的任务卡会这样写## 任务 为 discount 模块实施 TDD。 需求compute_discount(price, discount_code) 根据优惠码计算折扣价。 规则 - price 必须是正数否则抛 ValueError - discount_code 为 None 时返回原价 - SAVE10 减 10%SAVE20 减 20%其他 code 抛 ValueError - 结果保留小数点后 2 位 约束 - 只修改 discount.py 和 test_discount.py - 不要修改 agent_tasks.md - 第 1 步先写失败测试禁止跳过红灯 - 每次改动后都必须运行python -m pytest -v - 测试全部通过后附上执行终端的最后 20 行作为证据有人会觉得写任务卡很麻烦但我建议别省。“禁止跳过红灯”这句话几乎能避免一半的 Agent 乱来。3.2 第一回合让 Agent 输出红灯测试收到任务卡后Agent 通常先读目标文件发现discount.py不存在于是开始写测试。测试大致会是这样import pytest from discount import compute_discount def test_none_returns_original_price(): assert compute_discount(100, None) 100 def test_save10_discount(): assert compute_discount(100, SAVE10) 90 def test_save20_discount(): assert compute_discount(100, SAVE20) 80 def test_unknown_code_raises(): with pytest.raises(ValueError): compute_discount(100, UNKNOWN)这一回合的运行结果自然是 ModuleNotFoundError 一类的失败。对追求效率的人来说这一步很像浪费算力但我不允许跳过。只有先确认测试确实触碰到了未实现的功能后续的实现才具备可信度。这一步最容易被新手误解为“浪费时间”。我第一次跑类似任务时也试着让 Agent 直接一口气写测试和实现结果它生成的测试基本是在给自己背书全是一些明显会通过的弱断言。我们需要的不是“一次过”而是“先红后绿”的可信过程。3.3 第二回合拿红信息驱动实现红灯信息进来后Agent 在下一轮创建discount.py。实现大概率长这样PRICE_CODES {SAVE10: 0.9, SAVE20: 0.8} def compute_discount(price: float, discount_code: str | None) - float: if price 0: raise ValueError(price must be positive) if discount_code is None: return round(price, 2) if discount_code not in PRICE_CODES: raise ValueError(funknown discount_code: {discount_code}) return round(price * PRICE_CODES[discount_code], 2)然后它会执行测试输出四个测试全过的绿色结果。到这里“红-绿”循环已经转完一圈。关键动作是我要求它在产出后把测试输出贴回。大部分 Agent 默认不会主动贴因为它觉得自己“大概已经完成了”。必须在任务卡里明确要求“附加执行终端的最后 20 行作为证据”。这一步对排查特别有用如果测试没跑你立刻能发现。3.4 第三回合重构和边界用例绿灯不代表结束。我会再给 Agent 一条指令现在做小步重构。把折扣比例表和价格校验抽成两个独立小函数并补充以下边界测试 - price 为 0 和负数时抛异常 - 折扣后出现 0.01 舍入精度问题时结果仍是两位小数Agent 会抽出apply_discount、validate_price这类函数并补三个边界测试。跑完依然是绿灯。这里的意义是让“重构”这个平时最容易被人略过、又最容易带来恐慌的阶段也能被自动化地持续验证。说实话传统 TDD 里最难坚持的环节就是重构。人总想“能跑就行别动了”。Agent 不存在这种心理包袱只要测试护栏在它就敢拆。这反而是 AI 驱动 TDD 给人感受最直观的变化。3.5 人工审查清单最后我会做一道人工审查不会全信绿灯。主要看三件事第一测试是否真正断言了外部行为而不是断言 Agent 自己可控的内部变量。第二是否出现“测试绕过实现”的情况比如 mock 得过狠。第三改动范围有没有越过白名单。我把这道审查叫“最后一道防火线”。AI Agent 可以提高 TDD 的执行速度但执行对不对责任始终在人这边。4. 上下文构建与测试策略选型4.1 Agent 需要哪几类输入跑过几轮就会发现Agent 的成败大多取决于上下文构建而不是模型在某个瞬间的灵感。我基本喂三类信息需求描述、现有接口规格、失败日志。需求描述要能转成测试用例否则 Agent 会自己脑补业务接口规格要能约束住 Agent 不产生幻觉字段尤其是参数名和返回类型失败日志则是运行时驱动力缺了它 Agent 只能靠猜。举个例子如果需求描述里只写“算折扣价”Agent 很可能生成一个没有参数类型约束的版本。我会把接口签名固定为compute_discount(float, Optional[str]) - float写进任务卡它就不会自由发挥成字典参数或返回字符串。4.2 单元测试、接口测试和契约测试怎么选在 AI 驱动 TDD 的场景里测试类型会明显影响 Agent 效率单元测试对 Agent 最友好输入输出看得见失败定位最直接适合做主循环。接口测试适合做回归护栏尤其是内部实现改了、对外契约不变时它能兜住行为变化。契约测试适合多团队协作的系统边界。Agent 做局部模块时很难单独判断契约是否成立需要人先约定契约再交给 Agent 去实现。我目前的建议是先专注单元测试等绿灯稳定之后再让 Agent 基于接口清单生成一套数据驱动的接口测试别让它一上来就写又大又全的端到端验证。端到端测试失败时定位成本太高Agent 很难判断是前端、后端还是中间件的问题。4.3 一套能复用的任务卡模板把任务卡做成模板固定下来能让团队里的多个 Agent 行为一致。简化版长这样## 任务 需求[一段可判定的描述] 约束 - 接口签名固定为 [签名] - 测试框架pytest - 先写失败测试再写实现禁止跳过红灯 - 运行命令[命令] - 允许修改的文件[白名单] - 禁止触犯的文件[黑名单] 最终交付 - 贴出执行后的退出码和测试摘要 - 列出本轮新增的测试用例名称及其目标这套模板我用了很久最大作用是降低 Agent 的自由度。Agent 的通病是自由发挥TDD 的通病是过度依赖纪律任务卡正好把两股力量拧在一起。模板不是越多越好核心字段就是需求、接口、命令、白名单、交付物这五样够用就好。4.4 在不同代码规模下的调整在只有一个文件的小模块里任务卡可以简洁一旦进入一个中等规模的业务库上下文策略就要改。我会做两件事。第一把 Agent 的只读路径放宽到所有相关模块但写权限依然锁定在目标文件。第二额外提示它“先读调用方再读实现最后读测试”这个顺序能让它先理解现实约束而不是照着空想写方案。规模更大的模块我还会建议先让 Agent 输出一份“测试地图”把要覆盖的功能点列成清单人来确认后再进 TDD 循环。测试地图相当于开工前的设计评审成本很低却能把后续的无效迭代减少一大截。5. 实测踩坑红灯假绿、死循环和上下文污染5.1 假绿到底是怎么发生的最典型的假绿场景是这样的Agent 写了一个测试跑出来是红的但它在下一轮不是改实现而是把测试改成“反向验证”——把断言值和实现值调换一跑竟然绿了。如果不看 diff很多人会误以为功能真的修好了。我后来用一个简单方法治住了它在任务卡里加一句“禁止修改测试来适配实现行为只能修改产品代码来让测试通过”。如果还要更硬核就把测试文件冻结到只读权限让 Agent 在“红”阶段只能产出新测试在“绿”阶段只能改实现。这一招治假绿立竿见影。症状可能原因常见解法测试和实现一起变退出码为 0Agent 在“自证清白”冻结测试文件权限或加禁止修改测试的指令测试覆盖了错误行为需求描述本身模棱两可人工复审测试语义补全需求规则绿灯但断言全是弱判断Agent 写了“保险断言”要求每个测试至少包含一个反向断言和边界断言5.2 Agent 进入了原地画圈第二种常见问题是死循环。举个例子Agent 修好测试 A 后测试 B 挂了它转头修 B结果 A 又挂。看日志会觉得它很努力但其实一直在原地画圈。我的止损办法是给循环设迭代上限并且对每一轮单独做一次回归。如果出现“改 A 导致 B 失败”要求 Agent 必须先回退引入问题的 diff再尝试新方案。上限到了还没结果就停下来问人不要继续烧 token。这个技巧其实来自真人结对的经验一个开发者在同一处反复碰壁时最好换一种思路而不是在同一方向硬刚。Agent 也一样。5.3 上下文被仓库噪音污染当输入包含大型代码库时Agent 阅读太多无关文件之后会开始改错地方。我见过它在无关的类里新建字段来满足一条测试险些把不相干的逻辑带进核心流程。这类问题的根源是上下文污染。处理方式很简单严格控制白名单并在提示里加一句“不要搜索与目标模块无关的文件”。白名单加搜索限制的组合能显著减少空间幻觉。越是大型仓库越要舍得把信息面收窄。5.4 与 CI 搭配的护栏TDD 的终点是 CI。Agent 在本地怎么跑最终还要在 CI 上做回归。我推荐的落地方案是把 Agent 生成的测试文件和实现文件提交到特性分支由 CI 上的 pytest 作为强制校验只有 CI 绿灯才能合并。CI 还可以增加一条高权重检查“测试失败后禁止合并”。这样即使 Agent 在本地出现了假绿过了人工那一关也骗不过 CI 的真实验证。对我而言CI 才是真正最终的验证官。6. 最后几点体感整体体感是AI Agent 并没有把 TDD 变成“不需要人”的流程而是把“人的测试纪律”变成“可执行的任务”。人在其中更像需求和质检角色压力释放是真实的。实际掉过最深的坑是以为 Agent 能直接全仓库级自动补测试。想少走弯路的朋友我建议从一个小模块、一组测试、一条白名单开始练习把“先红后绿”跑顺再谈扩大边界。如果让我说一个最实用的经验就是这句话把 Agent 当成一个很有热情但偶尔离谱的结对伙伴给它上下文边界、给它执行反馈、给它裁判权它才表现得像个合格的 TDD 执行者。不给边界和裁判权它更像一个想象力过剩的实习生。这个差别比换哪个模型都重要。