Agent

mit6.824

29人浏览 · 2026-05-19 11:27:12

mit6.824 · 2026-05-19 11:27:12 发布

图源网络
在这里插入图片描述

降低任务的不确定性
工具多 → 需要 MCP 统一接口
Agent 多 → 需要 A2A 统一通信
一个任务的可验证性，定义了它的自动化天花板
X轴是控制，Y轴是信任
高效地“指挥”它做，以及如何低成本地“验证”它做得对不对
非阻塞式的异步协作
决策日志，快照回溯
不再是一个实时聊天窗口，而可能是一个类似版本控制系统的、带标记的决策审查列表
把人工智能代理的能力，直接嵌入到他们原生的工作产物里
上下文感知的、极度精准的控制
非线性，可分支可恢复的决策树

问题	表现	缺失
个人信息	模型不知道你的企业资料、个人偏好	企业内部知识
调用工具	无法查询实时数据、外部信息	工具执行能力
执行计划	任务复杂时容易迷失方向	规划与编排能力

由此衍生了 Agent 的落地

二、RAG（检索增强生成）

RAG = Retrieval-Augmented Generation

当用户提出问题时，Agent 先从**企业内部的数据库或知识库**中检索相关内容，再将检索结果与用户问题一起发送给大模型，由大模型综合整理后给出回答

用户提问 → 检索企业内部数据库 → 获取相关资料 → 与问题一起喂给大模型 → 综合输出答案

不依赖大模型自身的知识，而是借助外部知识库
本质是查找和检索，没有复杂的推理思考
解决了"大模型不知道我的企业信息"的问题

三、Tool Use（工具调用）

RAG 只能从已有数据库中查找，但实际问题往往需要实时数据和外部服务。例如查航班、查天气、看新闻等。

让大模型学会调用外部工具。执行流程：

用户：查一下北京到厦门的航班
→ Agent 调用航班查询工具（传入出发地、目的地）
→ 获取航班数据
→ 大模型整理成自然语言输出给用户

新问题

企业可能有几十上百种工具，每个工具的 API 接口、编写规范、数据格式各不相同，需要统一管理。

四、MCP（模型上下文协议）

MCP = Model Context Protocol

用于**统一管理各种工具的接口规范**，确保：

不同工具的数据传输格式一致
工具调用过程中的安全性
Agent 与各类工具的顺畅连接

工具少 → 工具多 → 接口不统一 → 需要 MCP 统一协议

五、ReAct（推理+行动）

ReAct = Reason + Act

在复杂任务中，Agent 不仅执行动作，还要**边思考边行动**

发现问题 → 思考原因 → 选择工具 → 执行 → 评估结果→ 如数据不够 → 继续搜索 → 再评估 → 直到完成

做市场调研时：

先搜一个网页，发现数据不够
分析原因，继续搜下一个网页
发现关键信息，再深入挖掘
综合所有数据给出报告

模式	说明	适用场景
ReAct	`边做边想，动态调整`	`开放式探索任务`
Plan	先制定计划再执行	流程固定的任务

六、Multi-Agent

当任务过于复杂（如新能源车市场调研），单 Agent 无法高效完成，需要多个 Agent 协作

主 Agent（Leader / 大脑）
    ├── 子 Agent 1：竞品分析
    ├── 子 Agent 2：目标用户分析
    ├── 子 Agent 3：市场趋势研究
    └── 子 Agent N：数据汇总

各子 Agent 执行后 → 结果汇总给主 Agent → 输出完整报告

主 Agent 制定整体计划
将任务分解，分配给不同子 Agent
各子 Agent 分别执行自己的子任务
结果汇总回主 Agent
主 Agent 综合整理后输出

七、A2A（Agent to Agent 协议）

当 Agent 数量增多时，Agent 之间的通信和协作成为新挑战。例如子 Agent 发现"目标用户设定不合理"，需要通知主 Agent 调整计划。

作用

A2A = Agent to Agent

定义不同 Agent 之间安全交互信息、协同工作的协议标准，确保：

Agent 之间的信息传递安全
任务状态同步
协作流程顺畅

工具多 → 需要 MCP 统一接口
Agent 多 → 需要 A2A 统一通信

八、Workflow（工作流）

对于流程固定的任务，可以人工预设执行顺序：

第一步：竞品分析
第二步：确定目标用户
第三步：生成报告

模式	控制方式	灵活性
ReAct	模型`自主`决定下一步	`高`
Plan	模型制定计划后执行	中
Workflow	人工预设固定流程	低

如 Claude Code 在编译器中执行代码时，需要人工确认后再继续：

写完代码 → 人工确认（yes/no）→ 编译器执行 → 继续下一步

九、State（状态管理）

Agent 执行任务时，如果中途遇到错误（网络中断、页面加载失败、电脑关机），从头开始执行会非常低效。

记录 Agent 的**状态快照**：

记录内容：
├── 当前执行到哪一步
├── 使用了哪些工具
├── 获取了哪些结果
└── 哪里失败了

Agent 下次启动时，可以从**中断处继续执行**，而非从头开始

十、Harness Engineering

当让 Agent 执行代码时，需要一个隔离的虚拟环境，而非在本地编译器中直接运行。

如果所有代码都在本地执行，会导致存储混乱
本地资源（内存、CPU）会被耗尽
执行失败可能影响本地环境

Agent 生成代码 → 发送到外部虚拟环境（沙箱）→ 执行 → 返回结果 → 不影响本地状态

十一、Computer Use

很多企业软件（如古老的 ERP 系统）仍以人机交互为主，Agent 无法通过 API 调用。

让 Agent 模拟人类的操作方式：

看屏幕识别界面元素
点击按钮
填写表单
读取返回信息

本质上是让 Agent 操控电脑来完成工作，而非通过代码接口。

Agent 落地的生态：

┌─────────────────────────────────────────────────────────────┐
│                        大模型（LLM）                         │
├─────────────────────────────────────────────────────────────┤
│  RAG：解决"不知道我的信息"问题         │  Tool Use：调用工具 │
├─────────────────────────────────────────────────────────────┤
│           MCP：统一工具接口规范                               │
├─────────────────────────────────────────────────────────────┤
│  ReAct：边思考边行动    │    Plan：先计划后执行              │
├─────────────────────────────────────────────────────────────┤
│              Multi-Agent：多智能体协作                       │
├─────────────────────────────────────────────────────────────┤
│  A2A：Agent 之间通信协议    │    Workflow：固定流程控制      │
├─────────────────────────────────────────────────────────────┤
│  State：状态管理（断点续传）   │   Harness：沙箱执行环境      │
├─────────────────────────────────────────────────────────────┤
│               Computer Use：操控电脑界面                      │
└─────────────────────────────────────────────────────────────┘

扎克伯格收购 Minus 的案例揭示了一个重要趋势：AI 落地的核心挑战已从"模型能力"转向"工程能力"。单纯的聊天式 AI 无法满足实际业务需求，需要结合 RAG、工具调用、多 Agent 协作、工作流编排等一系列技术，才能让 AI 真正成为能执行复杂任务的智能助手

形成了一个从数据获取→工具调用→任务规划→多 Agent 协作→持续执行闭环。

协作的维度错配

复杂的智能代理需要一个超越聊天的全新协作范式

这个观点，来自法律科技公司Legora的首席技术官雅各布·劳里森。在他看来，目前以聊天为基础的人机交互，在处理复杂、长时程任务时已经彻底破产。

他有一句极其精准的原话，“聊天是单维的、低带宽的接口，它试图将复杂的工作树压缩成线性的东西。”

核心逻辑链是，复杂的代理工作，本质上是一个并行的、多分支的决策树。而聊天界面，却强行将这个多维的树状结构，压缩成一个单维的、线性的对话流。

这种维度的错配，导致了大量上下文信息的丢失，也就是他所说的“上下文腐烂”，最终让用户失去控制，协作彻底失败。

劳里森认为，我们正处在一个生产力瓶颈转移的时代，单纯的执行工作已经极其廉价，而真正的瓶颈，在于前期如何精准地规划，以及事后如何高效地审查。而聊天，恰恰在这两个最关键的环节上，都彻底失灵了。

协作的带宽，是设计下一代人工智能工具的起点。

新生产力瓶颈

为了理解为什么聊天界面会失效，我们必须先看清一个更底层的经济学转变。

主讲人劳里森指出，在人工智能时代，生产力的核心瓶颈，已经从“执行工作”本身，转移到了“规划工作”和“审查工作”这两端。

他的逻辑推演是这样的。首先，大型语言模型极大地降低了“执行”工作的边际成本，使得生成代码、草拟文件这类任务，变得近乎免费和瞬时。

这听起来很棒对吧，但它直接导致了价值链的压力，向上游的“规划”和下游的“审查”两端挤压。

规划，也就是精确地定义需求和规格，仍然高度依赖昂贵的人类智慧
审查，也就是验证人工智能生成的结果是否正确、可用，同样需要耗费大量的人类时间。

劳里森用了一个非常形象的例子，审查一个巨大的代码合并请求，那种体验是极其痛苦的。

这就像高频金融交易，单次下单执行的成本可以忽略不计，真正的壁垒，在于前期策略的研发，也就是规划，和事后风险的控制与复盘，也就是审查。

因此，他得出一个结论，未来真正有价值的人工智能工具，其核心不再是单纯地把任务完成，而是要能够构建一套高效的、人机协同的规划与审查工作流，去精准地解决这两个新的、也是更昂贵的瓶颈。

当我们还在为人工智能能“做什么”而兴奋时，真正的落地，已经在思考如何高效地“指挥”它做，以及如何低成本地“验证”它做得对不对

生产力的进化，永远是瓶颈的转移。看懂瓶颈在哪里，才能抓住真正的机会。

验证者法则

如果说瓶颈决定了我们应该关注什么，那么“可验证性”，就决定了人工智能本身能力的上限。

主讲人劳里森引用了一个非常重要的原则，叫做“验证者法则”。核心思想是，如果一个任务是可解的，并且它的结果是易于验证的，那么它最终一定会被人工智能解决。

这个法则的底层逻辑，根植于机器学习的反馈循环机制。人工智能代理是通过不断修正错误来学习和解决问题的。

一个任务的输出结果，越是能够被客观、快速、低成本地验证，那么它提供给人工智能的反馈信号就越清晰，学习效率就越高。因此，人工智能会首先在那些极其容易验证的领域，取得颠覆性的突破。而在那些难以验证的领域，进展则会非常缓慢。

劳里森用法律领域的例子做了个精彩的对比。检查一份合同里，所有定义好的术语是否都被使用了，这是一个非常容易验证的任务，就像代码检查一样，人工智能可以做得很好。

但是，要去判断这份合同的整体诉讼策略是否高明，就几乎无法验证。因为唯一能真正验证它的，只有当它真的被拿到法庭上，由法官来裁决。这个验证的延迟和成本都太高了。

这个法则也提示了一个二阶风险。对于那些无法直接验证的任务，我们常常会寻找一个“代理指标”来间接验证。比如，让新合同看起来和过去成功的旧合同相似。

但过度依赖这种代理指标，可能会导致“应试教育”式的人工智能。它会为了满足指标而优化，但这可能与任务的真正目标背道而驰。

一个任务的可验证性，定义了它的自动化天花板。认识到了这一点，才能准确预测人工智能在不同行业的渗透顺序和深度。

控制与信任

理解了瓶颈和边界之后，我们终于可以构建一个有效的人机协作框架。主讲人劳里森认为，所有高效的人机协作，都建立在两个核心变量的平衡之上，那就是控制和信任

控制，指的是人类能够将其知识，有效注入到代理工作中去的能力。换句话说，就是我能不能在我需要的时候，精准地去引导和修正代理的行为。
信任，直接决定了你需要审查多少工作。如果你对代理的信任度很低，你就需要检查它执行的每一步，审查成本会极高。如果你对它有极高的信任，你甚至可以完全不看过程，直接采纳结果。

这是一个非常优雅的降维打击。它把一个模糊的“协作体验”问题，变成了一个可以在二维坐标系里量化的模型。X轴是控制，Y轴是信任

我们所有的努力，都是为了将人工智能代理的工作，从左下角的“低控制、低信任”区域，移动到右上角的“高控制、高信任”区域。

在这个理论框架下，优化人机协作，无非就是两条路径。

要么，通过技术手段，让我们拥有在关键节点，一键否决、精准修正的高控制力
要么，通过提升代理的可靠性和透明度，让我们敢于放手，实现高信任度的自动化。

所有优秀的人工智能产品，都是在这两个变量之间，找到了特定场景下的最优解。

信任增强策略

那么，如何具体地增加我们对人工智能代理的信任呢？主讲人劳里森给出了三种非常实用的工程策略。

第一种，是任务降维，把不易验证的任务，变得容易验证。他举例说，直接验证一份新合同的好坏很难，但你可以寻找一个“代理指标”。

比如，你可以设定一个测试，看这份新合同，和我们公司过去那些最成功的“黄金合同”有多相似。通过这种方式，一个主观的、难以验证的任务，就被降维成了一个相对客观、可以量化的比较任务。

第二种，是任务分解。把一个巨大的、笼统的任务，分解成多个更小的、更易于验证的子任务。

比如，“起草一份合同”这个大任务，可以分解为：选择风险配置、确定判例文件、应用标准格式、检查术语定义等等。然后，你可以把那些需要高度人类判断的部分，比如选择风险配置，留给人类自己，而把检查定义这种类似代码检查的、极易验证的工作，交给代理去完成。

第三种，是设置护栏。

通过主动限制代理的能力范围，来确保它不会做出格的事情。就像给一个机器人设定一个活动范围，它只能在指定的三个文件目录里读写，只能访问指定的几个网站。通过限制它的“自由”，来换取我们对它的“信任”。因为它能做的事情变少了，所以它能犯的错误也变少了。

这三种策略的本质，都是通过精心的系统设计，降低任务的不确定性，从而让我们敢于把更多的工作，放心地交给人工智能。

信任不是凭空产生的，它是由清晰的边界、可量化的指标和可控的风险共同构建的。

驾驭工作树

解决了信任问题，我们再来看如何增加控制。主讲人劳里森认为，要真正控制一个复杂的代理，我们必须把它想象成一个“工作树”，一个有向无环图。而单纯依赖前期的“规划”来进行协作，是远远不够的。

为什么呢。仅靠前期规划来协作，就像你和一个同事详细地讨论好了方案，然后他就消失了，直到他交付最终成品之前，你再也听不到他的任何消息。这中间的过程，完全是一个黑盒。如果在执行过程中，他遇到了你没预料到的特殊情况，他根本不知道该怎么办。

这就是前期规划的致命缺陷，它无法处理执行过程中的意外。

那么，更高级的控制方式是什么呢？劳里森提出了两个核心机制。

第一个，叫“技能”。技能，允许你将人类专家的判断，预先编码成一个个可复用的模块，嵌入到工作树的执行节点里。

比如，你可以创建一个技能来规定，当审查合同的终止条款时，如果发现有特殊的欧盟法律适用，应该如何处理。这样，当代理在执行中遇到这种情况时，它就能像调用一个函数库一样，自主地、正确地处理这个特殊情况。

第二个，叫“询问”。当然，你不可能预先把所有意外都写成技能。当代理遇到了技能库也无法覆盖的全新问题时，它不应该卡住，也不应该瞎猜，而应该触发“询问”机制，主动把问题和上下文抛给人类，请求决策。

这种“技能”加“询问”的组合，完美地平衡了自主性与受控性，让协作从一次性的指令下达，变成了一个动态的、持续注入人类智慧的过程。

控制的本质，不是在开始时把缰绳抓得多紧，而是在过程中，拥有在任意节点介入和修正的能力

异步协作模式

即便是有了“询问”机制，一个现实的问题是，如果人类不能及时回应，代理的工作流就会被阻塞，整体效率会大打折扣。

那么最理想的交互模式是怎样的呢？主讲人提出了一个非常优雅的解决方案：非阻塞式的异步协作

当代理在执行任务时，如果遇到了不确定的节点，也就是需要人类决策的地方，它不应该停下来傻等。它应该被授权，根据当前信息，先自主地做出一个临时决策，让自己“不被阻塞”，然后继续向下执行。

最关键的是，它必须把这个不确定的决策，以及做出决策的依据，清晰地记录在一个“决策日志”里。

这样，人类专家就可以在自己方便的时候，去异步地审查这个决策日志。如果人类认可代理的临时决策，那就什么都不用做。如果人类不认可，他就可以轻松地一键推翻或者修正这个决策。

这个设计听起来简单，但解决了人机协作中的一对核心矛盾。既避免了因为等待人类而导致的效率瓶颈，又避免了因为人类的频繁打扰而破坏专注的工作流。

将人与机器的协作，从一种“同步问答”，升级为一种“异步审查”。

这要求我们重新设计用户界面。我们需要的不再是一个实时聊天窗口，而可能是一个类似版本控制系统的、带标记的决策审查列表。在这里，人类审查的不是代码，而是机器的判断

让机器在不确定时先行一步，但把最终的裁决权留给人类。这才是控制与效率的完美平衡。

高带宽产物

聊天的带宽太低，异步日志又不够直观，那么最终极的人机协作界面应该是什么样子的？

主讲人劳里森的答案是，我们应该在“高带宽的产物”中进行协作。这里的“产物”，指的是那些领域专家们日常工作中，就已经在使用的、高度结构化的文件，比如律师的合同文档，程序员的代码库，或者分析师的电子表格。

他的核心思想是，不要再把人从他们熟悉的工作环境中拉出来，让他们去和一个抽象的聊天机器人对话。而是反过来，把人工智能代理的能力，直接嵌入到他们原生的工作产物里

这样，协作就从脱离上下文的对话，变成了在具体工作中的直接互动。

他举了自己公司的例子。在他们的系统里，律师不需要在聊天框里告诉代理“请修改第三条款”。他只需要在文档里，直接用鼠标高亮第三条款，代理就会立刻理解，并且只修改被高亮的那一部分。这就是上下文感知的、极度精准的控制

另一个例子是“表格化审查”。当代理完成了对一批合同的审查后，它不会生成一份冗长的报告，而是自动生成一个交互式的表格

这个表格，会把所有合同中发现的、需要人类决策的风险点，清晰地、结构化地罗列出来，让人一目了然，可以快速做出判断。

这种嵌入式的、基于产物的协作范式，是真正的高带宽交互。把复杂的、树状的代理工作，自然地映射到了同样是结构化的工作产物上，彻底解决了聊天带来的维度错配问题。

代理不再是一个与你对话的外部工具，而是成为了正在编辑的文档本身的一部分，一个被赋予了超能力的协作者。

系统逻辑闭环

现在，我们把前面所有的逻辑节点串联起来，完成整个协作范式演进的逻辑闭环。

这一切的起点，是生产力瓶颈的转移。执行成本的崩塌，将压力传导至“规划”与“审查”两端，这定义了新时代人工智能工具的核心战场。

而验证者法则，则为这个战场划定了清晰的边界，一个任务的“可验证性”，决定了它被自动化的上限。

在这个背景下，传统的聊天范式，因其“低带宽”和“线性”的本质，与复杂工作“树状”的结构产生了维度错配，导致协作失败。

为了解决这个问题，我们需要一个全新的协作框架，它建立在控制和信任这两个核心变量之上。

我们可以通过任务降维、分解和设置护栏来系统性地增加信任。同时，通过引入技能和询问机制，来驾驭复杂的工作树，获得远超前期规划的动态控制能力。

而最终，承载这一切的终极界面，不是任何形式的对话框，而是嵌入在领域原生工作产物中的高带宽交互模式。它通过上下文感知和异步审查，实现了控制与效率的完美平衡。

从经济学瓶颈出发，到信息论的带宽限制，再到系统工程的控制与信任框架，最后回归到人机交互的界面范式革命

这就是从“为什么聊天不够好”到“什么才是足够好”的完整推演。理解这个闭环，才能真正把握高级人工智能代理的未来。

argue

雅各布·劳里森的整套逻辑非常严密，但如果我们以一个更挑剔的系统架构师视角，对他进行一次红队演练，会发现几个值得商榷的假设前提。

第一，他假设了人工智能的“执行”质量已经足够高。他认为执行已经廉价到可以忽略不计，但现实是，在很多领域，人工智能生成的初稿质量参差不齐。一个低质量的执行，会指数级地增加下游“审查”的负担，形成一个“垃圾进，审查成本更高”的负面循环。

第二，他低估了聊天作为“输入”的优势。他精准地指出了聊天作为“协作和输出”界面的缺陷，但自然语言在任务启动和快速指令下达方面，依然是目前效率最高的“通用接口”。完全抛弃它，可能会牺牲灵活性和易用性。

第三，他可能忽视了“高带宽产物”的规模化成本。他所描绘的、为每个垂直领域深度定制交互界面的愿景，是工程上的最优解，但实现成本极其高昂。在商业竞争中，这种“完美”的解决方案，很可能因为开发周期长、无法规模化，而被“足够好”的、通用的聊天机器人方案在市场上抢占先机。

所以，一个更现实的终局，可能并非是二选一的彻底替代，而是一个混合模式

用“聊天式”的自然语言，来完成高效的任务输入和启动
系统自动将任务切换到“产物嵌入式”的高带宽界面，来进行复杂的过程协作和审查。

这就像我们开车，口头告诉导航目的地，然后在地图界面上进行具体路线的微调。将不同交互模式的优势，在工作流的不同阶段进行组合，这可能才是通往未来的路径

Agent Infra

uptime ，真正重要的是「可重入」。让一个进程一直活着，并不是目标。真正重要的是：当它中断、失败、迁移之后，能不能在任意时间点重新进入执行，并且完整保留状态、上下文和环境。大规模 agent 系统调试必须要有
Agent 也需要事务性处理 Agent 的失败模式需要的是老朋友：ACID 事务、确定性恢复、状态对账。未来的 agent 底层，很可能会比大家想象的更像数据库系统
我们可能需要一种「面向 Agent 的编程语言」。理想状态下，它既有 Rust 那样的安全性，又有 Lisp 的元编程能力。可追踪、可回滚、可审计应该是语言的第一等公民(Ruby?)
数据库并没有过时，而是被低估了。关系型数据库在学术和工程层面，成熟得没有创新可做。这反而是它最大的价值。真正的前沿不在于重新发明数据库，而在于：如何把这些稳定的原语，重新组合成 Agent 的执行与状态骨架。
线性 workflow 在真实世界里是走不通的Agent 会分叉。会并行。会在中途失败，然后从别的地方继续。那种“人类可读的、一步一步往下走”的抽象，在长时间运行的 agent 行为面前，很快就会崩溃。非线性、可分支、可恢复是基础要求
人月神话 Brooks 定律依然成立，除非你的人才密度极高把大量资金摊在庞大的团队上，往往会被协作成本吞噬。真正有效的方式是用极少数、极高密度的人，去解决极难的问题。
用「人类协作」去类比 Agent，是一个危险的错觉。人力车夫很难直觉理解 F1 赛车的物理规律。同样，用人类的协作方式去设计多 Agent 系统，很可能从一开始就错了