LLM Wiki

Appearance

Built 26/04/17 08:59commit 0e73818

如何让 Agent 跑得更久 ​

中文 | English

摘要 ​

要让 agent 长时间运行而不漂移，关键不只是改 prompt，而是优化它周围的环境：把工作拆成明确角色或产物，让仓库和运行时可读，再加入持续验证和恢复的控制回路。

实用清单 ​

  • 给 agent 清晰的规划表面：planner、规格、冲刺契约或执行产物，把模糊目标变成明确交付物。
  • 当质量重要时，把“做”和“评”分开：用 evaluator、QA pass 或独立 review 回路，而不是依赖自我评估。
  • 把状态保存在耐久产物中：计划、决策日志、交接文件和仓库内文档，能让长时间运行在重置或长会话间仍保持一致。
  • 尽可能把持久 session 状态与实时上下文窗口分开，这样恢复能力就不会依赖某一种不可逆的 compaction 策略。
  • 让应用可读：暴露 UI 状态、日志、指标、trace 和可重复启动路径，让 agent 直接检查行为。
  • 保持仓库可导航：用简短的 AGENTS.md 当地图，把深层指导放进索引化文档，而不是塞进一个巨大指令文件。
  • 用机械方式强制不变量：lint、结构测试、架构边界以及有恢复提示的错误消息都能降低漂移。
  • 把清理当作闭环的一部分：周期性重构和 slop cleanup 可以阻止坏模式在多小时或多天的运行里不断积累。
  • 连 harness 本身也要重测：随着模型能力提升，删除那些已经不值得复杂度成本的脚手架。
  • 如果构建 harness 不是你的核心工作，就应考虑直接使用托管式 meta-harness，而不是自己拥有完整的 loop、sandbox 和工具运行时栈。

常见失败方式 ​

  • 一个巨大的 prompt 或 instruction file，把所有规则混在一起。
  • 让同一个 agent 同时负责构建、打分和给自己盖章。
  • 把关键上下文放在聊天、Slack 或人类记忆里，而不是放在仓库中。
  • 让 agent 操作一个黑盒，却不给它看运行时信号。
  • 不断增加 harness 复杂度，却从不检查这些复杂度是否仍然负重。

经验法则 ​

如果 agent 跑不久，问题通常不是“让它更努力推理”，而是“让任务更容易被检查、验证和恢复”。长时间运行的性能来自控制系统，而不只是更长的 prompt。

来源 ​

相关页面 ​