当 Agent 从模型调用，走向系统工程：OpenAI 和 LangChain 的两种实践
过去一段时间，业界关于 AI Agent 的讨论，大多还是围绕着模型能力展开：模型会不会推理、能不能拆解任务、会不会调用工具、上下文够不够长…但当 AI Agent 进入真实的生产环境时，问题会变得更具体，更加工程化。 Agent 要解决的问题，不再只是一次模型调用，而是维护一套能持续运行的系统：模型要不断判断下一步，工具要被调用，结果要回传，上下文要维护，错误要被发现，用户反馈也要被记录下来。 刚好，OpenAI 和 LangChain 最近陆续发布了两篇关于 Agent 工程实践的文章，分别讨论了 Agent 现在面临的两个系统问题。OpenAI 讨论的是，Agent 工作流变长之后，性能瓶颈如何从模型推理，转向 API 往返、状态重建和上下文重复处理。LangChain 讨论的是，Agent 上线之后，光有 trace 还不够，系统还需要 feedback，才能形成持续改进的闭环。 虽然切入角度不同，但二者的共同之处在于：Agent 正在从"模型调用"，走向"系统工程"。
Agent 的第一个工程问题，是速度
在《使用 WebSocket 加速 Responses API 的智能体工作流》中，OpenAI 用 Codex 举了一个例子：当你要求 Codex 修复一个错误时，它会扫描你的代码库以寻找相关文件，阅读这些文件以构建上下文，进行编辑，并运行测试以验证修复是否生效。在底层，这意味着数十次往返的 Responses API 请求：确定模型的下一步操作、在你的电脑上运行工具、将工具输出发回 API，如此往复。
图注：实战中的 Codex Agent 循环
上图展示了典型的 Agent 工作流：从模型决策到工具执行，再到结果回传，最后再进入下一轮判断。 过去，在 GPU 上运行大语言模型 (LLM) 推理是 Agent 工作流循环中最慢的部分，因此 API 服务的开销很容易被掩盖。但随着推理速度不断提升，在一次完整的 Agent 任务执行过程中，累积的 API 开销变得越发明显。 OpenAI 提到，过去在 Responses API 中，GPT-5 和 GPT-5.2 这类模型的运行速度大约是 65 TPS；在发布专门针对编程优化的快速模型 GPT‑5.3‑Codex‑Spark 时，目标为实现数量级的飞跃：通过针对 LLM 推理优化的特定 Cerebras 硬件，使运行速度超过 1,000 TPS。 为了让用户体验到新模型的真实速度，OpenAI 开始着手降低 API 开销，解决验证请求、处理上下文、网络跳转、状态重建这些链路带来的性能瓶颈。 凭借在单次请求的关键路径延迟 (critical-path latency) 方面进行多项优化：
- 内存缓存：在内存中缓存已渲染的 Token 和模型配置，从而在多轮对话中跳过耗时的 Token 化处理和网络调用。
- 减少网络跳转带来的延迟：通过消除对中间服务（例如图像处理服务）的调用，转而直接调用推理服务本身，从而降低延迟。
- 优化安全堆栈：改进安全架构，使特定分类器能够更快地标记违规对话。
TTFT（首 Token 延迟）性能提升了 45%，但对于 GPT‑5.3‑Codex‑Spark 来说，这些改进依然不够。
WebSocket 的重点，不只是换了一个协议
OpenAI 的方案是重新构思传输协议，为 Responses API 引入 WebSocket 支持。背后的架构思路是，不要把 Agent 的每一轮请求都当成一次完全独立的调用，而是将请求变成持久性连接。 在传统方式下，每一轮请求都可能要重新建立连接、重新发送完整对话历史、重新处理可复用的上下文。即使对话的大部分内容没有变化，系统仍然要为完整历史承担重复处理成本。随着 Agent 工作流变长，这种成本会持续累积。 WebSocket 的思路是保持一条持久连接，并在连接存续期间缓存可复用状态。具体交互：使用相同的 response.create 请求体，并引入 previous_response_id 字段来承接上一条响应状态中的对话上下文。 此外，服务器还会维护一个连接级别 (connection-scoped) 的内存缓存，用于存储之前的响应状态。当后续的 response.create 请求包含 previous_response_id 时，直接从缓存中获取该状态，而无需从头开始重新构建完整的对话历史。 缓存的状态包括：
- 上一个 response 对象
- 之前的输入和输出项
- 工具定义及其命名空间
- 可复用的采样中间产物，例如此前已渲染的 Token
图注：从串行请求到重叠执行
WebSocket 方案的重点不是单纯换协议，而是通过持久连接和状态缓存，减少 Agent 多轮执行中的重复处理和等待时间。 经过两个月的 WebSocket 模式冲刺后，Alpha 用户的 Agent 的端到端工作流性能最多提升了 40%。
Agent 的第二个工程问题，是持续变好
上面 OpenAI 讨论的是 Agent 怎么跑得更快，下面再看 LangChain 讨论的另一个问题：Agent 跑起来之后，怎么持续变好。 LangChain 联合创始人兼 CEO Harrison Chase 在《Agent observability needs feedback to power learning》中提到，大多数团队最开始会把 Agent 可观测性当成 debug 工具：系统出错了，打开 trace，看看到底是哪一步出了问题。但只有 trace 还不够，团队还需要反馈，也就是一些能告诉你 Agent 表现如何的信号：它的行为到底有没有用、有没有被用户接受、有没有被拒绝、是不是低效、有没有风险，或者是不是错了。 这也是 Agent 可观测性和传统软件可观测性之间一个很大的区别。传统软件里，用户反馈和可观测性分开一点，问题不算特别大。但在 Agent 系统里，它们必须紧密连接在一起。Trace 不只是记录"发生了什么"；反馈也不只是最后给一个评分。
Agent 的学习，不只是改模型
LangChain 这篇文章提出：Agent 的"学习"，不只发生在模型层面。 它至少发生在三个层面： 第一是 model level。如果模型持续误判请求、选错工具、不遵守策略，那这些 trace 可以拿来更新模型本身，用于后续的 SFT 或 RL。 第二是 harness level。这里的 harness 可以理解成模型外面那一整套运行环境，包括 prompt、工具 schema、权限检查、控制流、记忆更新逻辑、路由、重试和 guardrails。很多时候，Agent 出错并不是模型没有能力，而是脚手架设计不合适。比如，工具描述写得太模糊；Agent 在写入之前应该先读取；系统 prompt 在某个场景下做了错误取舍。 第三是 context level。Agent 对上下文非常敏感，检索到的文档、记忆、用户偏好、工具返回结果、历史对话、环境状态，都会影响它的判断。如果模型是在错误或缺失的上下文下做出了"合理但错误"的选择，那要改进的就不是模型，而是哪些上下文应该被检索出来，哪些信息应该被存储，哪些内容应该被压缩，哪些内容应该被丢弃。
这也是为什么 Agent 可观测性不能只停留在"看日志"。如果你不知道 Agent 当时看到了什么、做了什么、后面发生了什么，就很难可靠地判断到底应该改进哪里。 但反过来，只有这些过程记录也不够。系统还得知道：哪些轨迹代表成功，哪些代表失败，哪些失败值得变成 eval，哪些行为正在随版本变化而改善。
Feedback 才能把 trace 变成闭环
LangChain 文章里最核心的一句话是：Traces are necessary, but not sufficient。就是说，Trace 是必要的，但并不充分。 原因很简单：trace 是记录，feedback 才是判断。没有 feedback，团队手里只有一堆轨迹；有了 feedback，才可以开始筛选成功样本、失败样本、重复错误、可转化成 eval 的案例，以及真正值得优化的行为。 这里的 feedback 也不只是用户手动点一个赞或踩。按照反馈来源，可以分成以下几类：
- 显式用户反馈，比如点赞、点踩、评分、文字纠错。
- 隐式用户反馈，比如 coding agent 生成的代码是否被采纳、diff 是否被回滚、测试是否通过；support agent 的 ticket 是否被重新打开；research agent 的回答是否被复制，或者用户是否反复追问。
- LLM 评估，用另一个模型评估回答是否有帮助、是否遵守策略、轨迹是否可疑。
- 确定性规则反馈，比如正则表达式、规则检查、危险命令是否在未经批准的情况下执行、回答是否包含引用。
只有把这些信号与 trace 关联起来，Agent 才可能形成持续优化闭环。 从工程角度看，Agent 的改进，不应该只靠人工翻日志，而要把生产环境里的真实使用，转化成结构化信号。
小结
把 OpenAI 和 LangChain 这两篇文章放在一起看，会发现它们谈的不是两个孤立问题，而是 Agent 工程化链路上的两个关键环节。 OpenAI 关注的是：Agent 能不能跑得更快。LangChain 关注的是：Agent 跑起来之后，能不能持续变好。 一个解决执行效率，一个解决改进机制。前者影响用户体验，后者决定系统能不能演进。 过去，Agent 常被概括为"模型加工具"。但现在，从这些实践看，它越来越像一个完整的软件系统。模型只是其中一部分。围绕模型的运行时、工具层、状态层、观测层和反馈层，都会成为 Agent 工程里的关键能力。
