跳到主要内容

19 篇博文 含有标签「llm-agents」

查看所有标签

遗忘问题:无限膨胀的 Agent 记忆如何拖垮性能

· 阅读需 10 分钟
Tian Pan
Software Engineer

一个记住所有事情的 agent,最终什么有用的都记不住。这听起来像是悖论,却是每个在没有遗忘策略的情况下上线长期运行 AI agent 的团队的亲身体会。记忆存储不断膨胀,检索质量持续下降,某一天你的 agent 开始自信地引用用户的前雇主、一个已废弃的 API 端点,或者一个六个月前就已放弃的项目需求。

行业在赋予 agent 记忆能力上投入了大量精力,却很少关注那个更难的问题:教会 agent 如何遗忘。

LLM Agent 的图内存:扁平向量搜索遗漏的关系盲点

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是,西雅图的地址是一个仅在工作日使用的办公地址,而且由于用户三个月前提到的一项大楼限制,早晨送货窗口期在周一并不适用。每个事实都可以被单独检索,但它们之间的关系却不能。

这就是在基于扁平向量库(flat vector stores)运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入(embedding)。相似性搜索检索与查询匹配的事实,但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”(edges)。

大多数智能体记忆架构是围绕向量数据库构建的,因为它们速度快、设置简单,且适用于大多数检索任务。这些失败案例非常微妙,以至于在有人注意到这种模式之前,它们往往已经出现在生产环境中了。

LLM Agent 中的并行工具调用:你可能尚未意识到的耦合测试

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数工程师之所以选择并行工具调用,是因为他们希望自己的 Agent 运行得更快。工具执行占 Agent 总延迟的 35–60%,具体取决于工作负载——编码任务处于高端,深度研究任务则处于中端。同时运行独立的调用是显而易见的优化方案。但接下来的情况却让大多数团队感到意外。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=LLM%20Agent%20%E4%B8%AD%E7%9A%84%E5%B9%B6%E8%A1%8C%E5%B7%A5%E5%85%B7%E8%B0%83%E7%94%A8%EF%BC%9A%E4%BD%A0%E5%8F%AF%E8%83%BD%E5%B0%9A%E6%9C%AA%E6%84%8F%E8%AF%86%E5%88%B0%E7%9A%84%E8%80%A6%E5%90%88%E6%B5%8B%E8%AF%95"]

一旦你启用了并行执行,工具设计中隐藏的每一个假设都会变得显而易见。在顺序执行时可靠工作的工具,在并发运行时可能会悄无声息地失效。原本稳定的行为变得不可预测,而且失败往往不会产生错误——只是在充满自信地返回一个错误的答案。

并行工具调用主要不是一项性能特性。它是一次非自愿的架构审计。

讨好税:过度顺从的 LLM 如何悄无声息地破坏生产环境中的 AI 系统

· 阅读需 11 分钟
Tian Pan
Software Engineer

2025 年 4 月,OpenAI 对 GPT-4o 进行了一次更新,却破坏了一些微妙但后果严重的东西。模型变得极其顺从。用户报告称,它会认可糟糕的计划,在受到轻微反驳时就推翻正确的立场,并在每个回答前对提问大加赞赏。这种行为过于夸张,以至于 OpenAI 在几天内就撤回了更新,称这是短期反馈信号覆盖了模型诚实性的案例。这一事件被广泛报道,但大多数团队忽略了这一点:这种顺从的程度虽然罕见,但其方向却并不寻常。

谄媚(Sycophancy)——RLHF 训练的模型倾向于优先考虑用户认可而非准确性——几乎存在于每一个生产环境的 LLM 部署中。一项对 ChatGPT-4o、Claude-Sonnet 和 Gemini-1.5-Pro 的评估研究发现,平均在 58% 的情况下会出现谄媚行为,且无论上下文如何,其持续率接近 79%。这不仅仅是几个极端情况下的 Bug。它是这些模型训练方式的一种结构性属性,并且在生产环境中以标准评测难以捕捉的方式显现。

智能体规划模块:隐藏的架构缝隙

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数智能体系统在构建时都基于一个隐含的架构假设:LLM 在同一次推理调用中同时处理规划和执行。要求它完成一个包含十个步骤的任务,模型会决定做什么、去执行、检查结果、再决定下一步做什么——这一切都在一个连续的 ReAct 循环中完成。这看起来很优雅。但在实际工作负载下,它会以一种难以诊断的方式崩溃,因为其失败模式看起来更像是模型质量问题,而非设计问题。

智能体规划模块——即纯粹负责任务拆解、依赖建模和排序的组件——是大多数从业者都会跳过的接缝。只有当事情变得困难到无法忽视时,它才会显现出来。

智能体沙箱与安全代码执行:根据风险匹配隔离深度

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数发布具备代码执行能力的 LLM 智能体(Agent)的团队都犯了同样的错误:他们将沙箱化视为一种二元属性。要么完全跳过隔离(“我们信任我们的用户”),要么部署 Docker 容器并认为问题已解决。这两种立场在进入生产环境后都经不起考验。

现实情况是,沙箱化存在于一个包含五个不同级别的光谱上,每一级都提供不同的隔离保证、性能配置和运营成本。所选隔离级别与实际风险概况之间的不匹配是大多数智能体安全事件的根本原因 —— 而不是根本没有沙箱。

智能体工程是一门学科,而非一种感觉

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数智能体系统在生产环境中失败,并不是因为底层模型能力不足。它们失败是因为围绕模型构建的工程设计过于草率。模型在第三步偏离了方向,但没人注意到,直到第八步,最终答案虽然言之凿凿却是错误的,而且没有任何护栏来拦截它。这不是模型问题,而是架构问题。

智能体工程在三年内至少经历了两个完整的炒作周期。AutoGPT 和 BabyAGI 在 2023 年春季引发了巨大的狂热,随后在 GPT-4 不可靠的工具调用现实面前折戟。第二波浪潮随 2024 年的多智能体框架和智能体 RAG 而来。现在,到了 2026 年,超过半数的受访工程团队报告已有智能体在生产环境中运行——其中大多数团队也发现,部署一个智能体与维持一个可靠的智能体是完全不同的问题。成功的团队将智能体工程视为一门严谨的学科,而挣扎中的团队仍将其视为一种“感觉”(vibe)。