企业官网建设流程全解析

摘要：从京东JoyCode公开的Patch Agent与Testing Agent协作机制出发，解释AI同时生成实现和测试时如何建立独立验收证据。

京东云开发者社区公开的JoyCode技术报告，把仓库级代码修复拆成多Agent协作：Patch Agent负责理解Issue、定位代码和生成候选补丁；Testing Agent在隔离环境里安装依赖、创建或运行测试，并形成PASS_TO_PASS与FAIL_TO_PASS等验证结果；失败还会进入轨迹压缩、相似经验检索和再迭代。

公开材料描述的是团队参加SWE-bench Verified的工程方法与厂商自报结果，不是某个京东线上系统的事故。把机制放进常见业务，可以构造一条优惠券Bug：部分退款时，优惠金额被重复返还。Coding Agent修改结算代码，同时新增一条单测。补丁和单测都由同一问题理解产生，如果Agent把规则误读成“按商品原价退款”，实现与测试可能严丝合缝地一起错。

这正是AI Coding最容易被忽略的质量风险：测试数量增加、流水线通过、补丁解释完整，都不代表业务Oracle独立。本文要给出的，是一条“问题契约—候选补丁—独立测试—对抗验证—失败归因”的仓库级回归方法。

京东公开架构里，Testing Agent为什么值得测试人关注

传统代码助手多停在补全或生成片段。仓库级Agent会读Issue、搜索文件、执行命令、修改多处代码、安装依赖并反复运行测试。测试对象不再只是最终diff，还包括它如何建立环境、选择测试、解释失败和决定停止。

京东公开图里，Patch Agent与Testing Agent在Docker环境中协作；Testing Agent会生成测试文件并运行，之后结果进入轨迹处理、经验检索和决策。这个结构的重要启发是：测试已经成为Agent工作流的一部分。但“工作流里有Testing Agent”和“验收证据独立”是两件事。只要两个Agent共享同一个错误前提，它们仍可能共同收敛到错误答案。

先冻结问题契约，别让Agent同时改题目和答案

优惠券Bug的独立契约应该在Agent改代码之前写好。契约不需要很长，但要包含原始现象、复现输入、状态前提、正确金额、禁止改动和至少一个反例。例如：订单原价120元，优惠20元，实付100元；用户退其中一件原价60元商品；退款必须遵循平台明确的分摊规则；已退款金额不能再次计入；历史整单退款用例不能退化。

最关键的是把契约放进只读区域。Coding Agent可以引用，不能修改。新增测试文件也不能成为唯一Oracle。验收要同时查看：原始失败能否在旧版复现；补丁后是否通过；变异补丁能否被测试杀死；旧回归集是否仍通过；修改范围是否超出授权目录。

一段真正承担质量判断的断言

不要只写assert status_code == 200，也不要只断言Agent生成的expected。把订单事实与业务规则写入独立fixture，再同时验证金额、状态与幂等副作用。

def test_partial_refund_keeps_coupon_allocation(order, refund_service): first = refund_service.refund(order_id=order.id, item_id="item-A") second = refund_service.refund(order_id=order.id, item_id="item-A") assert first.status == "SUCCESS" assert first.amount == 50_00 # 由业务契约给出，不由Agent推导 assert second.status == "DUPLICATE_REJECTED" assert order.total_refunded == 50_00 assert order.coupon_returned == 0 assert order.state == "PARTIALLY_REFUNDED"

这里检查了五件事：首次退款成功；金额符合独立规则；重复请求被拒绝；累计退款没有翻倍；优惠券没有被错误返还；订单状态正确。任何一项缺失，都可能让“测试通过”掩盖真实资金风险。

用变异测试检查新增单测是不是太弱

AI生成测试最大的诱惑是数量。十条测试看起来很勤奋，但可能都只覆盖正常路径。变异测试不需要大规模执行，先针对本次风险做三种人工变异：删掉幂等判断；把分摊金额改回原价；把退款状态更新顺序提前。正确的测试集应该至少让这三种错误全部失败。

如果变异补丁仍然通过，先不要继续让Agent补更多相似用例。回到契约层检查：是不是没有定义重复退款；是不是只验证返回值，没有查账本；是不是状态断言在Mock里被写死。这个排查顺序能避免模型在错误Oracle上越补越多。

Trace要记录首次错误，不要只保留最后一次成功

Coding Agent经常会经历“安装失败—改依赖—测试失败—改实现—再次通过”。如果报告只保留最后一轮，测试团队看不到它是否改了不该改的环境，是否删除失败测试，或是否通过放宽断言获得成功。Trace至少记录每轮命令、退出码、文件差异、测试集合变化、依赖变化和失败分类。

失败归因建议分成五类：问题理解错；代码定位错；补丁逻辑错；测试Oracle弱；环境或偶发性问题。这样模型升级后做Agent Regression Testing时，比较的就不只是一条总通过率，而是各类失败有没有迁移。例如总分上升，测试Oracle弱的比例却增加，发布质量仍然值得警惕。

把仓库级回归接进CI

最小CI可以分三层。即时层只跑受影响模块的编译、静态检查和高风险契约；夜间层运行完整回归、变异测试和多次稳定性检查；发布层增加人工diff审查、依赖审查与回滚演练。Agent生成的补丁只进入候选分支，没有独立证据不得自动合并。

每次模型、系统提示词、工具版本、仓库镜像或测试Harness变化，都用同一批高风险Issue重跑。除了通过率，还记录平均工具步数、失败重试、无关文件修改、测试被改弱、耗时与成本。Continuous Evaluation的目标不是每天得到一个漂亮分数，而是知道哪种能力变化正在把风险转移到别处。

测试工程师不是Agent流水线最后的点击人

京东公开方法说明，测试生成和执行可以成为Coding Agent的重要能力；真正进入企业发布流程时，测试团队仍要守住独立Oracle。最有价值的工作不是逐行和Agent比谁写得快，而是把业务规则冻结为契约，把风险变成能杀死错误补丁的样本，把Trace变成可复跑的证据。

你可以从团队最近修过的一条真实Bug开始：保存原Issue、旧版失败输入、正确业务结果和三个变异补丁；让Agent生成候选修复，但让独立pytest门禁决定是否通过。做到这一步，AI Coding才从“会写补丁”进入“可以被工程化验收”。

环境变化会伪装成补丁效果

仓库级任务经常需要安装依赖、选择解释器和启动服务。Agent为了让测试通过，可能悄悄升级库、换掉锁文件，或者使用本地已有缓存。结果在它的Docker里成功，进入CI却失败。每次运行应记录基础镜像摘要、语言与包管理器版本、依赖锁文件差异、环境变量和外部服务桩。候选补丁与基线必须在同一环境重跑，否则“修复前失败、修复后通过”可能只是环境不一致。

还要保留最早一次失败。首次错误往往最接近真实根因，后续错误可能只是Agent修补环境造成的噪音。如果Agent先遇到数据库连接失败，随后把集成测试改成Mock并通过，最终报告不能只写“全部通过”，而要标记验证强度已经变化。

测试文件本身也是审查对象

AI Coding评审通常盯生产代码，却容易忽略测试diff。需要单独统计删除了多少断言、Mock范围是否扩大、异常用例是否被改成跳过、超时是否被放宽、随机失败是否被重试掩盖。下面几种变化应自动标红：assert数量下降；skip/xfail增加；Mock从外部依赖扩大到被测函数；期望值改为直接读取实际值；捕获所有异常后不再失败。

测试审查可以形成独立质量门：生产代码修改由一个Agent提出，测试变化由另一个上下文隔离的审查器解释，再由确定性脚本检查危险模式。这样做不是迷信多Agent，而是减少同一推理链同时改实现和裁判规则的机会。

稳定性要用重复运行证明

一次通过无法区分真正修复和偶然成功。对并发、时间、网络和随机性相关Bug，应在固定种子与多个种子下重复运行，记录失败频率而不是只看最终状态。若旧版100次中失败20次，新版100次全过，这是候选证据；若新版偶尔仍失败，就应保留失败Trace继续归因，不能让Agent用自动重试覆盖。

发布报告至少列出：问题契约版本、补丁文件清单、新增与删除测试、变异杀伤结果、重复运行次数、环境指纹、遗留失败和回滚点。读者不需要相信Agent的自我评价，只需要核对这些可复跑证据。