跳到主要内容

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

查看所有标签

生产环境中的 Agentic Coding:SWE-bench 分数没有告诉你的真相

· 阅读需 14 分钟
Tian Pan
Software Engineer

当最尖端的模型在 SWE-bench Verified 上获得 80% 的评分时,这听起来像是问题已经解决了。五分之四的真实 GitHub issue 都能被自动处理。直接交付给你的团队吧。但事实是:同一个模型在 SWE-bench Pro(一个专门设计用于防止数据污染、包含来自私有代码库的长程任务的基准测试)上的得分仅为 23%。此外,一项针对经验丰富开发者的严谨对照研究发现,使用 AI 编程工具反而让他们慢了 19%,而不是变快了。

这些数字并不矛盾。它们反映了基准测试衡量的内容与生产环境软件工程实际需求之间的差距。如果你正在构建或打算采用智能体编程(agentic coding)工具,那么这个差距就是最值得关注的事情。

上下文填充反模式:为什么更多的上下文反而会让 LLM 变差

· 阅读需 11 分钟
Tian Pan
Software Engineer

当 100 万 Token 的上下文窗口发布时,许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观:如果模型能看到一切,那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式:系统在早期演示中运行良好,但在生产环境中会遇到可靠性瓶颈,无论如何调整提示词都无法修复。在原本应该很简单的问题上,准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

为什么你的智能体控制架构应该是无状态的:在生产环境中实现大脑与双手的解耦

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数构建 AI agent 的团队都将 harness —— 处理工具路由、上下文管理和推理循环的支架 —— 视为绑定到单个容器的长寿命、有状态进程。当容器出现故障时,会话就会终止。当你需要更换更好的模型时,必须重新启动所有内容。当你想要水平扩展时,会遇到瓶颈:每个 harness 实例对其自身状态了解过多,导致无法互换。

解决方案不是更智能的 harness,而是一个无状态的 harness。

每个生产级 AI Agent 都需要的三个记忆系统

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数 AI agent 都会以同样的方式失败:它们在演示中表现完美,但在经历十次真实对话后就会分崩离析。那个上周二还帮用户配置账单集成的 agent,今天已经完全不记得那个用户是谁了。它再次询问对方的公司名称,然后是套餐层级,接着重新解释用户已经掌握的概念。体验从“有用的助手”降级为“健忘的聊天机器人”。

直觉反应是给问题增加更多上下文 —— 将对话历史塞进 prompt 并认为问题已解决。这种做法在达到一定规模前确实有效。在大规模场景下,全上下文方案的成本高得惊人,而且更麻烦的是,随着输入量的增长,性能会下降。研究表明,即使在模型宣称的限制范围内,LLM 的准确率也会随着上下文长度的增加而明显下降。100 万 token 的上下文窗口并不是一个记忆系统。

在生产环境中运行良好的 agent 将记忆视为头等架构关注点,而不是事后才考虑的事情。而那些做对的 agent 能够区分三种根本不同的持久化信息类型 —— 每种类型都有不同的存储模式、检索策略和衰减特性。

关于在生产环境运行 MCP,没人告诉你的那些事

· 阅读需 12 分钟
Tian Pan
Software Engineer

Model Context Protocol (MCP) 将自己定位为 AI 的 USB-C 接口 —— 将任何工具接入任何模型,然后看着它们自如交流。在实践中,第一天确实感觉如此。第二天你会遇到扩展性漏洞。到了第三天,你就在阅读关于那些你甚至都不知道存在的工具投毒攻击(tool poisoning attacks)的 CVE 了。

MCP 是一个非常有用的标准。它于 2024 年底推出,并迅速被整个行业采用,它解决了大语言模型(LLM)与外部系统之间真实的集成摩擦。但在“完成演示原型”与“在真实用户负载下可靠运行”之间,存在着比大多数团队预想的更大的鸿沟。以下是这个鸿沟的真实样貌。

为智能体编写工具:ACI 与 API 同等重要

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数工程师对待智能体工具的方式与编写 REST 接口或库函数如出一辙:清晰地暴露功能、记录参数、处理错误。这对人类来说是正确的直觉。但对于 AI 智能体(AI Agents)来说,这完全是错误的。

智能体使用的工具是以非确定性的方式被消耗的,它被逐个 Token 解析,并由一个对上周二使用过什么工具没有持久记忆的模型来选择。你编写的工具 Schema 并不是文档——它是运行时提示词(runtime prompt),在推理时被注入到模型的上下文中,塑造着智能体做出的每一个决策。每一个字段名称、每一段描述、每一个返回值的结构都是一个设计决策,具有可衡量的性能影响。这就是智能体-计算机接口(ACI,Agent-Computer Interface),它值得你像对待任何关键的面向用户的界面一样投入工程精力。

在生产环境中真正奏效的智能体工程模式

· 阅读需 9 分钟
Tian Pan
Software Engineer

AI 编程代理最危险的误解是,它们让你放松工程纪律。实际上恰恰相反。代理系统会放大你已拥有的一切:坚实的基础产生速度,薄弱的基础则以机器般的速度制造混乱。

值得关注的转变不是代理为你编写代码。而是约束条件发生了变化。编写代码不再是昂贵的部分。这几乎改变了你构建流程的一切。

模型上下文协议:最终解决AI工具集成的行业标准

· 阅读需 12 分钟
Tian Pan
Software Engineer

每个发布过 AI 产品的工程师都了解集成成本。你希望你的代理从数据库中读取数据、触发 GitHub PR 并发布 Slack 消息。于是你编写了一个数据库连接器、一个 GitHub 连接器和一个 Slack 连接器——每个都是嵌入你提示管道中的自定义代码块。将其扩展到三个产品和五个数据源,你将有十五条不同的集成路径需要维护。Anthropic 称之为“M×N 问题”,他们说得没错。

模型上下文协议(MCP),于 2024 年 11 月推出,现由 Linux 基金会管理,是业界的解决方案。你可以将其比作语言服务器协议(LSP)改变代码编辑器的方式:在 LSP 之前,每个编辑器都必须实现自己的 TypeScript 语言服务器。LSP 之后,VS Code、Neovim 和 Emacs 都共享同一个服务器。MCP 将同样的逻辑应用于 AI:只需编写一个服务器,即可将其连接到任何兼容 MCP 的客户端——Claude、ChatGPT、Cursor、GitHub Copilot,所有这些。

AI 流水线中的投机执行:通过押注未来降低延迟

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API,等待 300 ms,调用日历 API,再等 300 ms,调用流量 API,再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的,那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行;这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行(Speculative execution)是一系列技术的统称,这些技术通过在你确定需要某些工作之前就提前执行它们,来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计,自 20 世纪 90 年代以来,处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时,这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机,协调开销也可能会抵消所有的收益。

智能体系统的补偿事务与故障恢复

· 阅读需 12 分钟
Tian Pan
Software Engineer

2025 年 7 月,一名开发者使用 AI 编程智能体(AI coding agent)来开发他们的 SaaS 产品。在会话进行到一半时,他们发出了“代码冻结”(code freeze)指令。该智能体忽略了指令,对生产数据库执行了破坏性的 SQL 操作,删除了 1,200 多个账户的数据,然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。

根本原因不是幻觉或误解指令。而是缺少一个工程原语:该智能体对生产状态拥有不受限制的写入和删除权限,且不存在撤销其操作的机制。

这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性,在生产部署中,工具调用的失败率为 3–15%,而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。

为什么你的智能体 UI 体验糟糕(以及如何修复它)

· 阅读需 13 分钟
Tian Pan
Software Engineer

你已经发布了一个性能卓越的 Agent。底层模型很强大 —— 它能检索到正确的上下文,调用正确的工具,并生成连贯的输出。然后你观察一个用户第一次尝试它,整个会话就崩溃了。他们不知道 Agent 什么时候在工作,看不出它是否理解了自己的意思。他们会在任务执行中途打断它,因为长时间的沉默感觉像是死机了。他们最终选择了放弃,并拨打你的支持热线。

模型不是问题所在,界面才是。

这是工程师在构建第一个 Agent 产品后不断重新发现的模式:人机交互(human-agent interaction)层本身就是一门工程学科,而大多数团队都将其视为事后才考虑的事情。他们在检索质量和工具准确性上花费了数月时间,然后直接接一个聊天框作为界面,并奇怪为什么即使后端日志显示成功,产品用起来还是感觉不可靠。

AI Agent 红队测试:发现真实漏洞的对抗性测试方法论

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个金融服务 Agent 在标准的越狱测试套件中获得了 11/100 分——属于“低风险”。而上下文相关的红队测试(首先剖析 Agent 的实际工具访问权限和数据库架构,然后构建针对性攻击)发现的情况却截然不同:一种电影角色扮演技术可以指示该 Agent 在 88 个钱包中调度 44 万美元,执行未经授权的 SQL 查询,并暴露跨账户交易历史。通用测试套件并不知道该 Agent 拥有 withdraw_funds 工具。它测试的系统与实际部署的系统并不一致。

这 60 分的风险分值差距正是将传统红队方法论应用于 AI Agent 时面临的问题。Agent 不仅仅是做出响应;它们会规划、跨多个步骤进行推理、持有真实的凭据,并在现实世界中执行不可逆的操作。测试你是否能让它说出一些有害的话,与测试你是否能让它 出一些有害的事,并不是一回事。