编程代理的胜负不在于提示词,而在于运行时基础设施
摘要
随着编程代理能力增强,瓶颈从模型质量转向支持长时间运行的基础设施,包括持久状态、权限、检查点、可观测性和成本控制。作者认为,最好的代理产品更像是运行时和工作流系统,而非仅仅改进提示界面。
随着编程代理能力增强,困难部分逐渐从“模型能否写代码?”转移。对于短任务,模型质量仍然是明显瓶颈——生成函数、修复 bug、解释堆栈跟踪。但当代理开始跨小时或天数工作时,瓶颈发生了转移。此时,更关键的是它们周围的 infrastructure。一个长时间运行的代理需要一个真实的运行环境:超越聊天历史的持久任务状态;涵盖仓库、终端、密钥和部署目标的适当权限;出现问题时能进行检查点和回滚;观察变更及其原因的能力;防止任务悄悄烧光预算的成本上限;以及在任何内容到达生产环境前的审查关卡。这就是为什么最好的代理产品越来越不像一个更好的提示框,而更像是一个围绕模型构建的运行时、工作流系统和部署平台。模型仍然重要。但对于严肃的工作,真正的问题是系统能否安全地维护上下文、执行操作、从错误中恢复,并在适当的时候将控制权交还给人类。这个基础设施层可能将成为编程代理真正的护城河。
相似文章
多智能体系统是运行时问题,而非提示工程问题
文章认为多智能体系统需要运行时基础设施层,而非更好的提示,引用了 MiniMax、OpenAI、Google 和 Anthropic 的发布。文章强调了工作者与验证者角色的分离以及多智能体设置的开销成本。
智能体需要控制流,而非更多提示词
文章认为,可靠的 AI 智能体需要在软件中具备确定性的控制流和程序化验证机制,而不能仅仅依赖复杂的提示词链。
@omarsar0: 随着我们针对长期任务中更复杂的编码代理使用(例如,动态工作流和 /goals),你会开始...
讨论了编码代理在复杂长期任务中的挑战,指出了奇怪的用户体验问题和低效的代理交互,并主张对代理框架拥有更多控制权。
编码代理的真正障碍不是代码质量——而是你是否能围绕它们构建一个可靠的循环
文章认为,AI编码代理的主要挑战不是代码生成质量,而是用户能否围绕它们构建可靠的循环,这将采用的障碍从模型能力转移到了工作流设计。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。