https://letsgetai.github.io/categories/agents/Recent content in Agents on The HertaHugozh-cnFri, 28 Aug 2026 00:00:00 +0000https://letsgetai.github.io/posts/ai-code-governance/Fri, 28 Aug 2026 00:00:00 +0000https://letsgetai.github.io/posts/ai-code-governance/<h2 id="场景10-周13147-条-commit">场景：10 周，13,147 条 commit</h2> <p>AI 辅助开发把代码的累积速度提高了一个量级，随之而来的问题是项目越写越“堆”：功能在快速扩张，结构在失去秩序。最直觉的应对是在 prompt 里加约束——“做最小实现”“不要过度抽象”。本文的结论是：这类事前限制控制不了膨胀，起作用的是事后治理——用固定门禁拦住可机械检测的结构问题（坏味道，如重复代码与死代码），用定期重构和去重抽象控制长期累积。核心证据来自 <a href="https://github.com/deepseek-ai/deepseek-harness">deepseek-harness</a> 的公开 commit 史。</p> <p>deepseek-harness（下文简称 DSH）是 DeepSeek 在 GitHub 上公开的仓库，在 2026-06-10 至 2026-08-21 的 10 周里积累了 13,147 条 commit，峰值一天 889 条。commit 主题与分支名中留有大量 AI 编码代理参与的痕迹（codex/ 分支前缀、.agents/ 目录）。这些数字全部来自公开数据，附录给出了可复现的统计命令，读者可以自行验证。</p> <p><img alt="每周 commit 数" loading="lazy" src="https://letsgetai.github.io/images/ai-code-governance/weekly-commits.png"></p> <h2 id="commit-史数据三个反直觉的分布">commit 史数据：三个反直觉的分布</h2> <p>提交类型按 commit 主题首词归类统计（命令见附录）：</p> <table> <thead> <tr> <th>类型</th> <th>数量</th> <th>占比</th> </tr> </thead> <tbody> <tr> <td>Merge</td> <td>5,891</td> <td>45%</td> </tr> <tr> <td>fix</td> <td>2,490</td> <td>19%</td> </tr> <tr> <td>docs</td> <td>1,435</td> <td>11%</td> </tr> <tr> <td>test</td> <td>1,028</td> <td>8%</td> </tr> <tr> <td>feat</td> <td>745</td> <td>6%</td> </tr> <tr> <td>refactor</td> <td>494</td> <td>4%</td> </tr> <tr> <td>revert</td> <td>36</td> <td>0.3%</td> </tr> <tr> <td>其他</td> <td>1,028</td> <td>8%</td> </tr> </tbody> </table> <p><img alt="提交类型分布" loading="lazy" src="https://letsgetai.github.io/images/ai-code-governance/commit-types.png"></p> <p>三个反直觉的发现：</p>https://letsgetai.github.io/posts/codex-goal-mode/Wed, 26 Aug 2026 00:00:00 +0000https://letsgetai.github.io/posts/codex-goal-mode/<h2 id="一个把-p95-压到-200ms-的任务">一个把 p95 压到 200ms 的任务</h2> <p>假设你让 agent 把服务的 p95 延迟压到 200 毫秒以下（p95 指 95% 的请求延迟低于这个值，是性能优化常用的目标——意思是只允许最慢的 5% 请求超过它）。这件事没法一条命令做完：要先跑 profile 定位热点，改实现，再跑基准对比，确认没有回退；没达标就换一个方向重来。十几轮工具调用，每一轮都改一点东西。开头 agent 清楚方向，二十轮之后它可能已经忘了最初的目标，或者在一个局部优化里越钻越深，或者自己宣布「完成了」——但基准根本没达标。</p> <p>这类任务有个名字：长程任务（long-horizon task），指需要很多轮连续动作、最后还要验证结果才算完成的任务。你的问题很具体：这类任务里 agent 为什么容易跑偏、停不下来？Codex 的 goal 模式能不能解决？什么时候用、怎么写？</p> <p>暂定回答：goal 模式解决的是「完成判定与续跑机制」的缺失，而不是模型能力本身。它适合有明确终点但路径不确定的任务；使用时要把目标写成可验证的证据面，并配合 token 预算；官方推荐的完整流程是先 /plan 访谈澄清，再 /goal 建立目标。</p> <h2 id="长程任务为什么难断崖不在单步在串起来">长程任务为什么难：断崖不在单步，在「串起来」</h2> <p>先排除一个常见误解：单步能力已经不是瓶颈。OpenAI 官方跑过 25 小时、1300 万 token 的连续任务实验，模型可以长时间稳定工作；METR 的度量进一步指出，「50% 可靠完成」的任务时长大约每 7 个月翻一番，2025 年初已经到了小时级——瓶颈是把长动作序列串起来，而不是单步技能。</p> <p>benchmark 把这种断崖画得更直白。在 SWE-bench Verified（500 个单 issue 任务）上 gpt-5.2 能做到约 72.8%；换成 SWE-EVO（48 个 release 级任务，平均涉及 21 个文件），同样的模型掉到 22.9%；SWE-bench Pro（1865 个企业级长任务）上 Top 模型约 23%；LongCLI-Bench 的 20 个长程 CLI 任务，SOTA 不到 20%，多数 agent 卡在 30% 进度之前。</p>