Agents

场景：10 周，13,147 条 commit AI 辅助开发把代码的累积速度提高了一个量级，随之而来的问题是项目越写越“堆”：功能在快速扩张，结构在失去秩序。最直觉的应对是在 prompt 里加约束——“做最小实现”“不要过度抽象”。本文的结论是：这类事前限制控制不了膨胀，起作用的是事后治理——用固定门禁拦住可机械检测的结构问题（坏味道，如重复代码与死代码），用定期重构和去重抽象控制长期累积。核心证据来自 deepseek-harness 的公开 commit 史。 deepseek-harness（下文简称 DSH）是 DeepSeek 在 GitHub 上公开的仓库，在 2026-06-10 至 2026-08-21 的 10 周里积累了 13,147 条 commit，峰值一天 889 条。commit 主题与分支名中留有大量 AI 编码代理参与的痕迹（codex/ 分支前缀、.agents/ 目录）。这些数字全部来自公开数据，附录给出了可复现的统计命令，读者可以自行验证。 commit 史数据：三个反直觉的分布 提交类型按 commit 主题首词归类统计（命令见附录）： 类型 数量 占比 Merge 5,891 45% fix 2,490 19% docs 1,435 11% test 1,028 8% feat 745 6% refactor 494 4% revert 36 0.3% 其他 1,028 8% 三个反直觉的发现： ...

一个把 p95 压到 200ms 的任务 假设你让 agent 把服务的 p95 延迟压到 200 毫秒以下（p95 指 95% 的请求延迟低于这个值，是性能优化常用的目标——意思是只允许最慢的 5% 请求超过它）。这件事没法一条命令做完：要先跑 profile 定位热点，改实现，再跑基准对比，确认没有回退；没达标就换一个方向重来。十几轮工具调用，每一轮都改一点东西。开头 agent 清楚方向，二十轮之后它可能已经忘了最初的目标，或者在一个局部优化里越钻越深，或者自己宣布「完成了」——但基准根本没达标。 这类任务有个名字：长程任务（long-horizon task），指需要很多轮连续动作、最后还要验证结果才算完成的任务。你的问题很具体：这类任务里 agent 为什么容易跑偏、停不下来？Codex 的 goal 模式能不能解决？什么时候用、怎么写？ 暂定回答：goal 模式解决的是「完成判定与续跑机制」的缺失，而不是模型能力本身。它适合有明确终点但路径不确定的任务；使用时要把目标写成可验证的证据面，并配合 token 预算；官方推荐的完整流程是先 /plan 访谈澄清，再 /goal 建立目标。 长程任务为什么难：断崖不在单步，在「串起来」 先排除一个常见误解：单步能力已经不是瓶颈。OpenAI 官方跑过 25 小时、1300 万 token 的连续任务实验，模型可以长时间稳定工作；METR 的度量进一步指出，「50% 可靠完成」的任务时长大约每 7 个月翻一番，2025 年初已经到了小时级——瓶颈是把长动作序列串起来，而不是单步技能。 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% 进度之前。 ...