Agent 运行越久，我就越不在意提示词

Reddit r/AI_Agents 新闻
agent-engineering harness-engineering eval validation agent-failures prompts architecture-rules

摘要

作者反思了长期运行的人工智能代理如何遭遇与初始提示无关的失败，并认为环境设计（工具、文档、验证、架构规则）更为重要。他们讨论了诸如 harness 工程、保持 AGENTS.md 文件精简、使用 linter 和评估器代理等概念，同时指出了成本权衡。

我曾经把大多数代理失败视为提示词的问题。现在我不太确定了。一旦代理运行了几个小时，失败就变得无趣多了：它读了一份旧的设计说明，从仓库中复制了一个糟糕的模式，认为自己的输出已经足够好，或者因为上下文窗口越来越拥挤而停止。更好的初始提示并不能真正解决这些问题。我读过一篇关于“harness 工程”的文章，这基本上是指代理周围的环境：工具、文档、验证、架构规则和停止条件。我第一次看到这个术语是在一篇 Milvus 的文章中，但让我印象深刻的根本不是向量搜索。我喜欢的一个细节是保持 AGENTS.md 文件小而精，把它当作地图使用，而不是把所有规则都塞进一个巨大的指令文件中。另一个细节是将重要规则转移到 linter 和运行时检查中，这样代理就不能轻易忘记它们。评估器代理这个想法我还在犹豫。在一个实验中，将规划器、生成器和评估器分开产生了一个可用的应用，而单独的代理产生的东西虽然能启动，但核心行为有缺陷。而且，成本大约增加了 20 倍。这是一个相当昂贵的默认设置。我目前的感受是：从严格的检查和真实的运行时证据开始，然后只为普通测试无法判断的事情添加一个单独的评估器。但也许这样仍然在循环中留下了过多的自我评估。对于在更长的任务中运行代理的各位来说，真正产生最大影响的因素是什么：更好的文档、更严格的架构、浏览器/日志访问，还是一个单独的评估器？
查看原文

相似文章

编程代理的胜负不在于提示词，而在于运行时基础设施

Reddit r/AI_Agents

随着编程代理能力增强，瓶颈从模型质量转向支持长时间运行的基础设施，包括持久状态、权限、检查点、可观测性和成本控制。作者认为，最好的代理产品更像是运行时和工作流系统，而非仅仅改进提示界面。

代理提示不是安全边界

Reddit r/AI_Agents

讨论了使用代理提示作为安全边界的局限性，认为仅靠提示不足以确保AI行为安全。