技能介绍

问题：只看到测试失败，看不到运行时状态

面对一段测试跑不过的代码，传统 debug 方式很容易陷入猜错方向的循环：你能看到断言失败，却看不到函数内部变量的真实值。单轮大模型修复也常常如此，模型可能只看 diff 猜一个原因，改完又引入新问题。TraceCoder 要解决的就是这个问题：用自动插桩拿到运行时追踪，再让模型基于真实执行轨迹而不是猜测来定位根因。

核心能力与关键步骤

TraceCoder 的核心是一个三智能体循环，LLM 推理全部由内置模型完成，execute_tests.py 只负责编译、执行和收集输出。

插桩 Agent：在不修改原逻辑的前提下插入 print / System.out.println / console.log 等探针，记录关键变量和分支状态。
分析 Agent：读取插桩执行结果，找出失败发生的上下文，判断根因并生成修复计划。
修复 Agent：按计划输出完整修复代码。

在此基础上还有两个重要机制：HLLM 会累积历史失败尝试，避免下一轮重复同样错误；回滚机制 保证每轮修复要么正向改进，要么丢弃并保留历史最优版本。

实际使用时，你需要提供待调试代码、测试代码和可选的语言参数。流程会先跑一次初始测试；如果直接通过就结束。否则进入最多 max_attempts 轮的调试循环，每轮都严格执行插桩、执行、分析、修复和评估。当连续 patience 轮没有改进时，会停止并返回当前最优代码。

适用边界与注意点

这个技能有几个硬约束。第一，所有推理都在本地模型内完成，不调用外部 API。第二，每次修复后必须用 execute_tests.py 验证，不能跳过测试直接交付。第三，输出必须是完整代码，不能只给 diff 或片段。第四，插桩不能引入副作用：不要修改循环边界、不要新增状态、不要改变 const / 引用语义，否则追踪结果会误导分析。

语言支持方面，Python 和 JavaScript 可直接使用；Java 已检测到 Java 11；C++ 需要先装编译器，如果检测不到可以编辑 language_config.json 手动填写路径。最后一条很重要：不要用 Python 重写 C++、Java 或 JavaScript 代码来分析。类型系统、指针/引用、未定义行为这些语言特有 bug，只有原生插桩和原生执行才能暴露。