Bojie Li (李博杰)

【本文是笔者在 A2M 互联网架构与 AI 技术峰会图灵大模型技术专场的受邀报告。】

下载 PDF：《能办成事的 Agent：实时与环境交互，从经验中学习》

大家好，欢迎来到 A2M 峰会。今天我分享的主题是 “能办成事的 Agent：实时与环境交互，从经验中学习” 。

先介绍一下我自己。我是 Pine AI 的联合创始人和首席科学家。

目前我们 Pine AI 的业务是，通过 AI 打电话帮助用户处理一些日常琐事和争议。在美国，打客服电话通常是一件很麻烦的事情。比如，你可能需要先等待半小时，然后还要花很长时间和客服沟通。如果客服不愿意帮你处理，你可能还会被转接到其他部门。所以整个流程下来，一个电话有时会耗费一两个小时。对很多人来说，并没有这么多时间去跟客服扯皮，有时候就吃了哑巴亏。还有一些人英语口语不够好，打电话沟通也很费劲。而 Pine 可以通过 AI 自动化地帮你完成这整个流程。

让今天的 AI 能帮用户端到端扯皮办事其实是非常难的，绝对不是 SOTA 模型套上一个 prompt 这么简单。大多数 AI 产品都是仅仅给用户提供一些信息，比如生成一个调研报告，而实际办事还是要用户自己去联系客服。

要让 AI Agent 能端到端办成事，其实非常困难。我们今天就来介绍一下其中一些核心技术挑战，以及 Pine AI 是如何解决这些问题的。

本文介绍了一种轻量级智能 DNS 分流解决方案，通过在本地搭建 Python DNS 服务器，同时查询国内外上游 DNS 并智能判断结果，有效避免 DNS 污染问题，同时保证国内网站获得最佳的本地解析结果。这种方案无需维护复杂的域名列表，能自动适应网络环境变化，为用户提供无缝的上网体验。

整体架构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

                                   +------------------------+
                                   |  应用程序 DNS 请求       |
                                   +------------------------+
                                              |
                                              V
+----------------+    +------------------------------------------------+
|                |    |      轻量级 Python DNS 服务器 (53 端口)           |
|  中国 IP 地址库  |--->|      同时查询国内外DNS，智能判断最佳响应            |
|                |    +------------------------------------------------+
+----------------+                  /                  \
                                   /                    \
                          +------------------+    +------------------+
                          | 国内 DNS 服务器    |    | 国外 DNS 服务器   |
                          | (114.114.114.114)|    | (1.1.1.1)        |
                          +------------------+    +------------------+

【感谢各位读者朋友发来的超过 50 条勘误！读者朋友们真的非常细心，发现了这么多错误，非常感谢指正！】

我的译作《图解大模型——生成式 AI 原理与实战》（Hands-On Large Language Models）已经于 2025 年 5 月上市，在京东、淘宝等平台上搜索 “图解大模型” 即可。

对本书的赞誉（中文版）

非常感谢硅基流动创始人袁进辉老师、微软亚洲研究院院长周礼栋老师、阿里巴巴 Qwen 算法负责人林俊旸老师、CAMEL-AI.org 社区创始人李国豪老师、特工宇宙（AgentUniverse）创始人仲泰老师倾力推荐！

译者序

大模型发展迅速，可谓 “AI 一天，人间一年”。很多人在百花齐放的模型花园中迷失了方向，不知道手头的应用场景应该用什么模型，也无法预判未来一年模型的发展方向，时常陷入焦虑。其实，如今几乎所有大模型都是基于 Transformer 架构的，万变不离其宗。

而《图解大模型》这本书正是帮你系统了解 Transformer 和大模型的基本原理和能力边界的绝佳资料。当图灵公司找到我翻译这本书时，我看到作者的名字就第一时间答应了，因为我当年就是读了 Jay Alammar 的 “The Illustrated Transformer” 这篇博客文章才真正弄懂 Transformer 的（本书第 3 章就是由这篇博客文章扩展而来的）。如今市面上讲解大模型的图书和文章浩如烟海，但本书的插图之精美、讲解之深入浅出是罕见的。本书从词元和嵌入讲起，不局限于生成模型，还包括很多人忽视的表示模型。此外，书中还包括文本分类、文本聚类、提示工程、RAG、模型微调等实用内容。

我非常荣幸成为这本书的译者，与编辑刘美英老师一起合作，把这本书带给中国读者。

花些时间读一下本书，系统地了解 Transformer 和大模型的基本原理和能力边界，就如同在大模型的探险之旅中拥有了地图和指南针。这样，我们不但不会担心新发布的模型一夜之间让长期的工程积累变得无用，还可以为未来的模型开发产品。模型能力一旦就绪，产品就可以马上起量。

希望本书能够成为大模型花园的观光巴士，让更多人看到大模型的全景。这样，大模型不断扩展的能力边界就是一场视觉盛宴，而非吞噬一切的怪兽；我们就有机会站在 AI 的潮头，实现更多梦想，获得更多自由。

本文是《图解大模型——生成式 AI 原理与实战》一书的配套资料。

我在面试候选人和参加业内研讨会时，常常发现很多人有大量实战经验，但对模型的基本原理知之甚少。为了帮助大家更好地理解本书，也为了方便部分有面试需求的朋友更有针对性地阅读本书，围绕本书各章主题，我系统梳理了大模型领域常见的面试题。其中的大多数问题都可以在书中直接找到答案，部分进阶问题可以从本书的参考文献或网络上的最新论文中找到答案。希望所有的朋友都能够带着这些问题阅读本书。

第一章：大语言模型入门

• Transformer 中的编码器和解码器有什么区别，只有编码器或者只有解码器的模型是否有用？
• GPT 跟原始 Transformer 论文的模型架构有什么区别？
• 仅编码器（BERT 类）、仅解码器（GPT 类）和完整编码器-解码器架构各有什么优缺点？
• 为什么说 Transformer 的自注意力机制相对于早期 RNN 中的注意力机制是一个显著的进步？
• 大语言模型为什么有最长上下文长度的概念？为什么它是指输入和输出的总长度？
• 大语言模型的首字延迟、输入吞吐量、输出吞吐量分别是如何计算的？不同应用场景对首字延迟、输入和输出吞吐量的需求分别是什么？
• 预训练和微调的两步范式为什么如此重要？基础模型通过预训练获得了哪些核心能力？微调在引导模型遵循指令、回答问题和对齐人类价值观方面起到什么作用？
• LLaMA-3 8B 的综合能力比 LLaMA-1 70B 的能力还强，是如何做到的？

在构建跨地域服务器网络时，例如《搭建全程美国 IP、无需手动设置代理的三层隧道》一文中使用的 VLESS 连接，我们常常会遇到一个效率问题：TCP 协议本身的拥塞控制机制。虽然 TCP 拥塞控制对于公共互联网至关重要，但在已经封装了应用层协议（可能自带流控或拥塞处理）的隧道场景下，外层 TCP 的拥塞控制反而成了累赘。

为什么要在隧道中禁用 TCP 拥塞控制和 Nagle？

1. TCP-over-TCP 问题：当你在一个 TCP 连接（例如 VLESS over TCP）内部传输另一个 TCP 连接的数据时，就会出现所谓的 “TCP-over-TCP” 问题。内层 TCP 和外层 TCP 都有自己的拥塞控制和重传机制。当发生丢包时，两个层级的 TCP 都会尝试重传，并且都会缩减拥塞窗口。这种双重处理不仅冗余，而且会导致性能急剧下降，尤其是在高延迟、高丢包的跨国链路上。内层 TCP 的重传计时器可能会因为外层 TCP 的延迟和重传而过早触发，反之亦然，形成恶性循环。此外，TCP-over-TCP 还会导致严重的队头阻塞（Head-of-Line Blocking）问题：外层 TCP 丢失的一个数据包会阻塞其中包含的所有内层连接的数据，即使这些内层连接完全不相关。这意味着一个用户的连接问题可能会影响到共享同一隧道的其他用户。
2. 应用层已有流控：隧道中传输的应用层协议可能已经实现了自己的流量控制和可靠性机制。在这种情况下，底层 TCP 的拥塞控制完全是多余的，它只会干扰上层协议的正常工作，限制其性能潜力。
3. Nagle 算法的延迟：Nagle 算法旨在通过将小的 TCP 数据包聚合成一个较大的数据包来减少网络中的小包数量，从而提高网络利用率。然而，在隧道场景中，我们通常希望数据能够尽快通过隧道传输，尤其是对于交互式应用（如 SSH）或实时性要求高的应用。Nagle 算法引入的延迟可能会对这些应用造成负面影响。禁用 Nagle（通过 TCP_NODELAY 选项）可以让小数据包立即发送，降低延迟。
4. UDP 在公共互联网上的困境：你可能会想，既然 TCP 这么多问题，为什么不直接用 UDP 建立隧道连接？不幸的是，UDP 在公共互联网，尤其是跨国链路上，经常受到运营商 QoS（服务质量）策略的限制，优先级较低，更容易被丢弃或限速，导致连接不稳定。因此，在很多情况下，我们不得不选择 TCP 作为隧道传输层协议，这就需要我们想办法优化 TCP 的行为。

因此，对于服务器之间的隧道连接（特别是跨地域连接），禁用外层 TCP 的拥塞控制和 Nagle 算法，可以显著提高隧道的吞吐量和响应速度。

解决方案：一个脚本

【本文是笔者在 2025 中国生成式 AI 大会 的主旨演讲，演讲内容是笔者与 AI 头脑风暴 2 小时的结果，然后在 Cursor 中与 AI 协作工作 3 个小时精修内容】

内容概要：一些团队在实际应用 AI 编程、 AI 写作时，发现效率提升并没有想象中的大。究其原因，往往是大量的知识仅在特定员工的头脑中，并未文档化，因此 AI Agent 就像一个新来的实习生，很难编写代码，就算是写出了代码，也不知道该如何测试。另一个原因是项目管理等内部工具只能通过 GUI 操作，对 AI Agent 不友好。如今文本推理模型的能力已经达到人类水平，不能完成任务往往是因为缺少背景知识和对 AI 友好的工具。

我们将从软件开发、项目管理、运营三个方面，讲解如何构建一个对 AI Agent 友好的 AI 原生团队。 AI 原生团队需要像开源社区一样，尽量使用有记录的语音和书面沟通，减少对人的单点依赖。 AI Agent 需要能够通过 MCP 访问公司内部的各种工具，有足够的上下文信息和测试环境高效工作。 AI Agent 需要记忆压缩机制、反思机制和检查点回溯机制，才能在无需人类干预的情况下持续工作一晚上，每个小时都产生有用进展。 AI 员工也需要与人类员工和其他 AI 员工主动沟通。这样，人类员工的大多数时间就可以用来做思考和讨论，而大多数重复性的执行工作就交给 AI。

《AI Agent 新探索：构建 AI 原生团队，使能 AI 员工》 PPT 下载（PDF）

以下是演讲全文：（PPT 是 2025 中国生成式 AI 大会上所用的版本，但文字说明并非实录，是笔者与 AI 头脑风暴生成的扩展版本）：

封面页

直播主题：AI Agent，注定爆发？！

时间：2025 年 3 月 13 日 20:00——22:00

方式：极客公园微信视频号「今夜科技谈」直播（连麦）

直播嘉宾：

• 靖宇｜极客公园 副主编
• 李博杰｜PINE AI 首席科学家
• 宛辰｜极客公园 记者

精华要点总结

• AI Agent 的核心特征是具备感知、规划和行动三大能力，能够自主收集信息、制定计划并执行动作
• 像 Manus 一样的通用 Agent 会模仿 “极客程序员” 而非普通人，具备计算思维，懂得何时使用代码和工具解决问题
• 当前 AI Agent 主要分为编译型 (如 Dify) 和解释型 (如 Manus) 两类，编译型是固定工作流，解释型是自主规划决策
• 编译型 Agent 与解释型 Agent 将长期共存，而非相互替代，不同场景有不同的最优解决方案
• 大模型存在 “100 倍成本定律”：芯片公司赚 10 倍，大模型公司再赚 10 倍，这揭示了模型定价与实际成本的巨大差距
• 基础模型是通用 Agent 能力提升的关键，人类很难想象比自己聪明 10 倍的东西，因此不要把人类的思维方式强加给 AI
• Manus 强调的 “Less Structure, More Intelligence” 与经典的《The Bitter Lesson》异曲同工，人类强加给 AI 的结构限制越少，AI 的能力上限就越高
• Claude 3.7 Sonnet 等新一代模型在工具调用和编程能力上有重大突破，为 Agent 发展奠定基础
• DeepSeek R1 的开源使得 RL (强化学习) 技术更易获取，降低了开发高质量 Agent 的门槛
• RL 训练是构建竞争壁垒的重要手段，可以将行业经验和专业知识转化为模型能力
• RL 训练所需的算力门槛没有想象的高，小模型经过 RL 训练后在一些垂直领域的能力可以超过大模型
• 多智能体架构不适合所有场景，在软件开发等领域可能会复制人类组织中的低效协作模式
• AI 编程工具在大型软件工程项目中也可以发挥很大作用，但需要高质量的代码工程基础，包括完善的文档、测试用例和标准化的接口
• 屎山代码 AI 编程工具难起作用，原因与新入职的实习生难以接手一样，都是代码中有太多没有文档化的 tribal knowledge
• Agent 技术的发展将推动软件工程实践的改进，促进代码质量和可维护性的提升，达到知名开源项目的标准，让更多项目变得 AI 友好
• Anthropic 提出的 MCP 协议为 Agent 生态系统的互联互通提供了标准化方案，将使多样化的专业服务相互连接而非相互替代
• OpenAI 的 Responses API、Realtime API 和 Anthropic 的 MCP 代表了 Agent 框架的发展方向
• Agent 的工作效率目前受限于视觉模型的延迟，人类在某些操作速度上仍有优势
• 虚拟机沙盒可以提供独立的工作环境，但需要更好的个人数据集成方案
• AI Agent 未来可能会分为 “快思考” (用户交互) 和 “慢思考” (后台处理) 两个部分协同工作
• 通用 Agent 是硬件、操作系统巨头的兵家必争之地，但大公司发布产品会相对谨慎
• 创业公司在 Agent 领域的机会主要在垂直领域，通过深耕特定场景积累专业数据和行业知识
• 编程、教育和人际沟通是最有可能率先出现成熟 Agent 应用的三大领域

为什么需要一个三层隧道

你所在的 AI 公司是否经常遇到以下情况？

• 需要访问只对美国 IP 开放的应用或大模型 API，如 OpenAI、Anthropic、Google 等
• 需要连接到美国的公司内网，但不想频繁设置代理

很多人搭建的是应用层代理，那么就需要在环境变量中设置 HTTP_PROXY，HTTPS_PROXY 等，但很多软件并不支持直接用环境变量配置代理，例如：

• Docker 容器内部并不会感知到外部的环境变量，如果要用现成的 docker compose 文件，又想让 docker 内的服务自动用上代理，就要折腾一番了。
• Docker 访问 docker.io 拉镜像和 build image 的时候，需要单独配置代理。
• 各种软件源，例如 pip、npm 等，需要单独配置代理。
• 一些软件，如 Google Cloud CLI，并不会从环境变量中读取代理配置，需要单独配置代理。
• 一些软件，如 Cursor，直接使用 IP 地址访问服务器，且使用的是非标准的 Websocket 协议，一些代理软件不兼容，或容易出问题。
• Node.js 服务端的一些库并不会直接检测 HTTP_PROXY 环境变量，而是需要配置 HTTP Proxy Agent，其中一些库（如 axios）在代理模式下还有 bug。
• 一些编译型语言的代码（如 C++、Go）常常自己组装 HTTP 请求发送，可能根本不支持配置 HTTP 代理。
• 一些 App（如 ChatGPT、Claude Code）使用额外的机制检测网络环境，如果发现代理，可能会拒绝服务，或者降低智商（例如用较差的模型代替 SOTA 模型）。

【本文首发于知乎回答《如何评价中国团队发布的通用型 AI Agent 产品 Manus？会成为下一个爆款吗？》】

总体来说，我觉得 Manus 是一个 idea 很好，但工程上还有很多打磨提升空间的产品。

关键创新：具备计算思维的 Agent

好多人都觉得它就是个更好的 computer use，其实第一眼我就发现一个根本区别：OpenAI Operator、Anthropic Computer Use 都是模仿普通人，而 Manus 是在模仿极客程序员。

OpenAI Operator / Deep Research 和 Anthropic Computer Use 打开的都是浏览器、桌面 GUI 和移动端 App，最后交付的结果是一段文字（最多带点 Markdown 格式）。而 Manus 一上来打开的是一个命令行终端，在里面用文本编辑器写了个 todo list，干活的过程中不断写代码做自动化，最后的交付件（Artifact）也是一段代码（交互式网页和图表）。

这让我一下子想到了 Jeannette Wing（周以真）博士在 MSR 给我们讲的 Computational Thinking（计算思维）。计算思维就是把日常生活和工作中的问题抽象化，然后用系统化的逻辑推理和自动化工具解决。我在科大期间也把计算思维介绍给了很多师弟师妹。