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

大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时，解决方案似乎显而易见：把对话存储起来，以后再检索。但这种直觉往往导致系统在演示中表现出色，而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统，与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟，大多数智能体项目正是悄然失败于此。

记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当，智能体不会崩溃；但它会让人感觉有些不对劲，自相矛盾，或者自信地重复着用户两周前纠正过的过时信息。

第一次一个 AI 编程代理破坏了一个团队的 CI 流水线——不是因为它编写了糟糕的代码，而是因为它生成拉取请求的速度超过了 GitHub Actions 的处理能力——这清楚地表明一些根本性的东西已经发生了转变。我们不再讨论一个更智能的自动补全工具。我们讨论的是一种完全不同的软件生产模式。

AI 辅助编程的发展轨迹迅速。自动补全工具改变了个人打字的方式。本地代理改变了单个会话能完成的任务。云代理现在正在改变团队构建软件的方式——将工作并行化到多个异步线程中，在提交 PR 之前运行测试，并且越来越多地处理长达 3 小时的任务，而开发人员则可以休息或转去解决其他问题。

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。

大多数声称在“生产环境中有智能体”的团队其实没有。调查一致显示，大约 57% 的工程组织已经部署了 AI 智能体——但当你应用严格的标准（LLM 必须能够规划、行动、观察反馈并根据结果进行调整）时，只有 16% 的企业部署和 27% 的初创公司部署符合真正的智能体标准。其余的只是加装了工具调用功能的“美化版”聊天机器人。

这种差距不在于模型能力，而在于架构。真正的自主智能体需要三个相互关联、协同工作的子系统：规划、记忆和工具使用。大多数实现只正确地完成了其中一个，部分实现了第二个，却忽略了第三个。结果是系统在演示中表现出色，但在生产环境中却会不可预测地失败。

大多数构建 AI 智能体的团队犯了同一个错误：他们在理解失败是什么样子之前，就开始着手评估基础设施。他们构建仪表盘、选择指标、连接评估器——然后发现他们的评估完全测量错了东西。六周后，他们得到了一份绿色的记分卡，但智能体却是坏的。

解决方法不是更多的工具。它是一系列特定的步骤，在你自动化任何事情之前，将你的评估建立在现实基础之上。以下就是这些步骤。

大多数智能体故障不会自行报告。没有崩溃，没有警报，没有堆栈跟踪。你的智能体只是默默地返回错误答案，跳过工具调用，或在任务中途停滞——而你直到三小时后用户投诉时才发现。从“在开发环境中正常运行”到“在生产环境中可靠”的差距，并非仅仅增加重试次数就能弥补。它关乎构建一个能够检测自身故障、对故障进行分类并在不半夜两点把你吵醒的情况下恢复的系统。

以下是自修复智能体管道在实践中的实际面貌。

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

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

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

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

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

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

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

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

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

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