activity-dev-harness 第一次接入真实仓库时，Developer Agent 的表现让人意外：在 playground 里能写出 90% 正确的 Lua 代码，但进入真实项目后，35 个 case 只通过了 12 个。

让 Developer Agent 修 100 个 bug。直觉上你会觉得：第一档最靠谱，第三档最不靠谱。AI 的自信程度和它的正确率之间，几乎没有正相关关系。这不是个别模型的问题，而是当前 LLM 的结构性缺陷。

AI Agent 的失败不是随机的，它有可预测的模式——这意味着可预测 = 可防御。很多人抱怨"AI 不好用"，本质上是把 AI 当黑盒在用：输入 prompt，祈祷输出正确。理解模型的激励结构（Reward），承认它和你的目标（Target）之间有 gap，然后用分层防御去系统性地缩小这个 gap。不要问"AI 为什么这么笨"，要问"我的系统哪层防御没做到位"。

让 Developer Agent 修 100 个 bug。直觉上你会觉得：第一档最靠谱，第三档最不靠谱。AI 的自信程度和它的正确率之间，几乎没有正相关关系。这不是个别模型的问题，而是当前 LLM 的结构性缺陷。

让 Agent 实现一个 694 行的模块——real_wiring.py，负责活动系统的真实布线逻辑。Agent 上来就开始写代码，前 50 行还不错，到第 100 行发现前面的数据结构选错了，但它没有回头改，而是在错误的基础上继续往下堆了 400 行补丁逻辑。最后交出来的代码"能跑"，但维护性为零。这不是 Agent “笨”。这是自回归生成的结构性问题——每个 token 都基于前面已生成的内

activity-dev-harness 项目的 Prompt 调优阶段，团队在 system prompt 上反复打磨了三周：角色定义、输出约束、few-shot 示例、CoT 引导。每改一版，跑几个 case 看起来都有进步。第三周末拉全量 35 个 case 回归，通过率 45%，波动范围 30%-65%。也就是说，同一份 Prompt，今天跑 65% 明天跑 30%。后来真正让通过率稳定到

AIReview 有 8 个工具（search_code、read_file、run_test 等），每个工具的 description + parameter schema 大约 100-150 token。这 900 token 是隐性固定开销，每次请求都在，你的规则和 diff 要跟它们竞争注意力。

上个月优化一个 Code Review Agent 的 system prompt。初版 800 token，效果还行，能抓住主要问题。团队陆续加了各种要求：代码规范要检查、安全漏洞要扫描、性能问题要提醒、文档一致性要校验……两周后 prompt 膨胀到 6200 token。跑了一轮 eval，通过率从 78% 跌到 52%。加了三倍的细节，效果反而砍了三分之一。这不是个例——几乎每个认真做 A

一个 Developer Agent 初始配了 12 个工具：读文件、写文件、运行命令、搜索代码、查文档、跑测试、看 git log、看 diff、格式化代码、检查类型、检查 lint、查依赖。看起来很全面——Agent 应该什么都能干了。工具少了 58%，通过率反而提高了 16 个百分点。

Config Risk Assessment 系统上线第一周，指令遵循率 67%。System prompt 4000 token，把风险评估的所有规则、所有场景定义、所有输出格式都写在一起——一份完整的"操作手册"。团队做的第一件事：排查模型具体在哪些指令上不遵循。中间 1500 token 的遵循率只有 48%——接近抛硬币。而这 1500 token 恰好放着最细致的评估规则：“数值类配置变