为什么编码代理这么笨？

总体情绪

• 许多人同意，当前的编码代理在实践中确实显得“笨”，但看法分化：
  • 一些人说，近期顶级模型加上更好的设置，已经大体修复了文章里提到的痛点。
  • 另一些人则表示已经为此沮丧了数月，尤其是在非平凡、长期存在的项目上。

Harness vs. 模型

• 几位评论者认为，大多数问题出在 harness/编排上，而不是模型本身的限制：
  • 默认提示词很差；没有强调子代理、并行性或角色分离。
  • 一些 harness（例如较新的版本）可以启动许多异步子任务；另一些则仍然是串行的，或者很脆弱。
  • 人们描述了自定义编排器，它们把任务委派给更便宜/更快的模型，并使用不同角色。

子代理、并行性和模型选择

• 体验参差不齐：
  • 有些人报告，自主代理表现非常好，能够接收工单并打开 PR，或者在同一个仓库里运行多个代理。
  • 另一些人则发现子代理会拖慢进度并恶化结果。
• 动态模型选择（聪明 vs. 便宜）目前大多仍是手动的，或由提示词驱动；完全自动的难度估计被认为很难。

代码质量和审查工作流

• 很多人抱怨 AI 写出的代码“能跑，但很丑”：
  • 过度复杂、类型不够严格、架构不清晰、“品味”差。
• 建议的缓解办法：
  • 文档驱动开发；先和代理一起写规格/文档。
  • 在 AGENTS.md 和 markdown 的“单一事实来源”文档中编码项目哲学和风格。
  • 使用 hooks/审查子代理，根据明确的风格和“完成定义”自动批评并重写代码。

提示词、上下文和环境工程

• 一些人坚持认为，仔细设计上下文/提示词/环境至关重要：
  • 把模型看到的一切——文件、文档、结构——都视为提示词的一部分。
  • 构建本地工具和技能，而不是依赖通用插件。
• 另一些人则反驳说，大多数用户没有时间花几个月去搭建定制框架。

安全与沙箱

• 对拥有文件系统/网络访问权限的代理存在强烈担忧：
  • 建议使用沙箱/容器，但它们仍然存在逃逸和供应链风险（例如 .git 中的脚本）。
  • 有些人给代理只读的 git 访问权限，并在网络上隔离它们。

元话题：期望与成熟度

• 几位评论者表示，像“显而易见”的功能清单本应默认集成到 harness 中，但我们还处于“AI 时代”的早期。
• “如果你想要，就用代理自己把它做出来”与“多数人合理地期望开箱即用时表现更好”之间存在张力。