你的编程代理并没有变差。你只是从未测量过第一个版本。
摘要
本文认为,编程代理性能的感知下降通常归因于代理实例和配置的未跟踪变更,而非底层模型本身,凸显了当前 AI 代理工作流中缺乏基线测量的关键问题。
在最近关于代理的讨论中,我反复看到一个模式:有人报告他们的编程代理在几周之内“变差”了。回复分为两派:“是的,模型更新搞砸了”与“你在想象,模型没变”。两派都忽略了真正的问题所在。模型可能确实没变。但你今天运行的代理实例与六周前的那个不同:上下文窗口内容不同、会话历史不同、框架配置不同,这些细微的累积决策相互叠加。同样的模型,不同的行为。而你没有可比较的基线,因为你从未测量过最初的版本。
这就是我们当前部署编程代理时的结构性问题:我们将模型名称视为度量单位。“我们使用 Claude Code”或“我们切换到 Codex”,仿佛模型名称能告诉你那个特定代理在上一轮冲刺中在你的单体仓库(monorepo)里具体做了什么。它并不能。两位工程师在相同的代码库上运行相同的模型,但由于框架设置和会话模式不同,他们实际上运行的是不同的代理。当其中一个实例“变差”时,正确的问题不是“模型改变了吗?”,而是:该实例的行为特征发生了什么变化,你又是如何察觉到的?
对此看得最清楚的工程师是那些在实例层面保留记录的人。他们不会说“Claude Code 擅长重构”,而是会说“这个实例、在这个代码库上、经过这 30 个会话,它在这些地方赢得了信任,在那些地方没有”。
你目前是如何跨会话跟踪代理的行为漂移的?
相似文章
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败,例如上下文泄漏和幻觉细节,认为这些通常是基础设施问题而非模型缺陷。
你的 AI Agent 没坏,是你的控制框架没配好。来看看我是如何搭建这套系统,让它从“累赘”转变为能交付生产级代码的。
本文指出,AI 编程智能体的失败源于系统设计不佳,而非模型能力限制。文章提出了一套包含知识、护栏和反馈循环的三层“控制框架”,以可靠地交付生产级代码。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。
我分析了 50 多个 AI 团队如何调试生产环境中的智能体故障,结果令人意外
基于对 50 多个 AI 团队的访谈,作者指出生产环境中的智能体故障往往源于细微的提示词或配置问题,而非深层模型缺陷。文章主张采用版本控制、A/B 测试和实验跟踪等软件工程实践以提高可靠性。
规格驱动的智能体编程正在悄然削弱我们监督智能体的能力
作者认为,过度依赖 AI 编程智能体会导致人类开发者逐渐丧失关键的技术直觉和代码审查技能,并提出了诸如强制手动编码日等措施,以维持监督能力。