89 篇博文 含有标签「ai-agents」

多数构建 AI 代理的工程师将 80% 的时间花在思考使用哪种模型上，20% 的时间花在其他所有事情上。这个比例应该反过来。模型在这一点上几乎是可以互换的——决定你的代理是否能在生产环境中实际工作的是“线束（harness）”。

这个等式很简单：**代理 = 模型 + 线束。**如果你不是模型，你就是线束。而几乎所有真正的工程工作都存在于线束中。

大多数构建 AI 智能体的团队都将模型视为固定不变的产物。你选择一个基础模型，编写提示，连接一些工具，然后发布。如果智能体开始出错，你会调整系统提示或切换到更新的模型。在这种框架下，学习发生在“上游”——在 AI 实验室中，在预训练和 RLHF 阶段——而不是在你的技术栈中。

这是一种错误的思维模型。随着时间推移而改进的智能体，是在三个不同的架构层面上实现这一点的，其中只有一个层面涉及修改模型权重。了解这一区别的团队能够构建出质量持续提升的系统；不了解的团队则会不断手动修补相同的故障模式。

大多数智能体演示都是无状态的。用户提问，智能体回答，会话结束——下一次对话从头开始。这对于计算器来说没问题。但对于一个应该了解你的助手来说，这就不行了。

有用的智能体和令人沮丧的智能体之间的差距，往往归结为一点：系统是否记住了重要信息。本文将详细阐述如何在生产级 AI 智能体中构建持久化、个性化的记忆——涵盖其四阶段生命周期、分层优先级规则以及如果你跳过工程设计将遇到的具体故障模式。

大多数多智能体系统的失败，不是因为模型出了问题，而是因为"管道"存在漏洞。智能体在任务执行中途丢失上下文，将任务移交给错误的专家，或者因为不知道如何退出而陷入无限循环。根本原因几乎总是相同的：系统设计只关注每个智能体能做什么，却没有清晰定义工作如何在它们之间流转。

两个原语可以解决大部分问题：例程（routines）和交接（handoffs）。它们看似简单，但把它们做对，是一个能演示的系统和一个能上线的系统之间的关键区别。

大多数构建 AI Agent 的团队花费数周时间进行部署前评估，却几乎不测量 Agent 在生产环境中实际的行为。这正好本末倒置了。真正重要的指标——Agent 无监督运行的时长、寻求帮助的频率、承担的风险程度——只有在运行时，跨越数千个真实会话之后才能浮现。不去衡量这些，等于盲目飞行。

一项针对数千次生产部署和软件工程会话的大规模研究，揭示了一些真正令人意想不到的发现。呈现出来的图景，与大多数构建者的预期大相径庭。