AI Agent 设计与开发全生命周期方法论——基于李飞飞团队论文《智能体：探究多模态交互的发展前景》的提炼与重构

【摘要】“大模型即智能体”的判断，已经难以支撑复杂系统的设计与落地。基于李飞飞团队论文《智能体：探究多模态交互的发展前景》的系统梳理，可以看到 AI 正从静态生成模型转向可感知、可规划、可执行、可反馈、可进化的智能体系统。真正有工程价值的 AI Agent，不取决于参数规模本身，而取决于它是否被放进环境中，是否拥有记忆，是否能调用知识与工具，是否能够在行动后接受反馈并修正策略，是否具备稳定的治理边界。围绕这些核心判断，重构一套覆盖目标定义、架构设计、知识融合、训练优化、测试验证、部署运行、持续进化与治理控制的全生命周期方法论，既是技术路径的整理，也是下一阶段 Agent 工程化的基础。

引言

过去两年，行业对 AI Agent 的讨论异常密集。很多系统被冠以 Agent 之名，实际却只是把大语言模型接到工作流上，再包装一层任务分发逻辑。这类系统在演示阶段表现不差，一旦进入复杂环境，问题会迅速暴露。任务链路一长，错误会层层放大。环境状态一变，推理就开始漂移。工具调用稍有不稳，系统就会停在中间态。到了机器人、医疗、游戏、多智能体协作这些场景，单纯依赖语言生成的方案往往无法继续推进。

李飞飞团队的论文《智能体：探究多模态交互的发展前景》提供了一个更完整的观察框架。论文没有把 Agent 简化为“会说话的大模型”，而是把它界定为一种嵌入环境、理解情境、产生行动、接受反馈并不断提升的交互系统。这个界定很关键。它把 Agent 的重心从生成能力转回到了系统能力，从单轮问答转回到了闭环执行，从模型规模转回到了工程结构。

如果顺着这条线看，AI Agent 的设计就不应只讨论提示词、模型选型和工具链，而应回答更本质的问题。系统服务于什么目标。它处在什么环境中。它如何看见世界。它如何理解任务。它如何作出行动。它如何积累经验。它如何在不确定条件下保持稳定。它如何在高风险场景中受控运行。这些问题共同决定了 Agent 是否真正可用。

下面这套方法论，正是基于李飞飞团队论文的原始结构所做的提炼与重构。重构的目标很明确，不是重复综述内容，而是把论文中关于定义、架构、学习、应用、风险和治理的关键论点，整理成一套可以指导工程落地的全生命周期框架。对研发团队来说，它可以作为架构设计的共识底盘。对产品与平台团队来说，它可以作为评估 Agent 能力边界和演进路线的工作基线。

◆ 一、方法论的基本立场与工程边界

1.1 从模型视角转向系统视角

1.1.1 Agent 不是模型的别名

李飞飞团队在论文开篇部分回顾了人工智能早期的整体性理想。那个阶段对智能系统的理解，天然包含观察、规划、操作与环境交互，而不是把智能限定在某一类静态输入输出映射上。后来的研究分工越来越细，语言、视觉、规划、控制、知识推理各自推进，带来了性能提升，也带来了系统割裂。今天重新讨论 Agent，实质上是在把这些能力重新组合起来。

这个背景决定了一个基本判断。**Agent 不是大模型的别名，而是一个由模型、环境、记忆、知识、行动与反馈共同组成的系统。**如果只保留语言生成能力，哪怕模型再强，也只是一个强大的解释器，而不是完整的行动体。

为了把这个差异说清楚，可以先看下面这张对照表。

这张表背后对应的，不只是功能堆叠，而是设计哲学的变化。以前的系统更像一个“高智能接口”，现在的 Agent 更像一个“受约束的行动者”。前者追求语言表达与知识覆盖，后者必须面对环境约束、步骤依赖、执行反馈和失败恢复。

1.1.2 方法论的核心目标

基于李飞飞团队的定义，可以把 AI Agent 的工程目标重新表述为一句更适合落地的话。让系统在明确环境与明确约束下，通过多模态感知、结构化记忆、任务规划、工具执行和反馈修正，稳定完成复杂任务。

这句话里有五个关节点，后续方法论都会围绕它展开。

第一是明确环境。Agent 一定运行在某个环境里，可能是软件系统、模拟器、游戏世界、机器人空间、医疗流程，也可能是混合现实空间。环境不是附属物，而是设计起点。

第二是明确约束。没有约束的 Agent 不是智能体，而是高风险自动化。约束包括权限、时序、资源、隐私、伦理、法规和人类监督条件。

第三是多模态感知。论文反复强调，只有把视觉、语言、音频、环境状态等联合起来，Agent 才能减少脱离场景的幻觉。

第四是执行闭环。Agent 的关键不在一次输出，而在感知、规划、执行、反馈、修正的循环。

第五是持续进化。系统不是训完即止。真实场景中的交互数据、失败样本、红队测试结果，都是后续能力演进的资源。

1.2 全生命周期方法论的范围

1.2.1 生命周期不是流程图，而是约束链条

很多团队把生命周期理解成一个线性流程，先做需求，再做开发，再做测试，然后上线。这个流程没有错，但不足以描述 Agent。Agent 的各阶段并不是松散串联，而是彼此强依赖的约束链条。早期目标定义不清，后面的状态空间就会含混。环境建模不足，架构设计就会脱空。知识底座弱，推理就会漂移。评估体系不完整，部署后就只能靠事故推动修复。

所以，全生命周期方法论更适合用“链条”来理解。前一阶段的质量，直接决定后一阶段的上限。后期暴露出来的问题，往往都能追溯到更早的设计假设。

下面画出一个尽量稳定的全链路视图。

这个图里最容易被忽视的是两条回路。第一条是持续进化回流到架构、知识与训练阶段。第二条是治理贯穿部署与进化。这恰恰是李飞飞团队论文里最重要的工程含义之一。Agent 不是一次性交付物，而是长期运行系统。长期运行系统没有持续回流与治理机制，迟早会出问题。

1.2.2 生命周期的八个关键阶段

结合论文结构，可以把完整生命周期压缩成八个阶段。为了后文展开方便，先用表格给出概览。

治理并不单列为“最后一个步骤”，因为它不属于尾部动作，而属于全阶段约束。后文会把治理嵌到每个阶段里讨论。

◆ 二、目标定义与环境建模

2.1 目标定义决定系统上限

2.1.1 先问“为什么存在”，再问“能做什么”

李飞飞团队在论文动机部分提到，要回到系统存在目的这个问题。这一点对 Agent 特别重要。很多项目一开始就讨论模型选型、推理框架和多 Agent 编排，最后发现连最基本的问题都没有答清楚。系统到底是为了帮人做判断，还是替人执行步骤。它是提升效率，还是降低错误率。它面对的是普通用户、领域专家，还是自动化系统。只要这些问题没有明确，后面的架构设计就只能围绕模糊目标打转。

一个成熟的 Agent 项目，通常会在立项阶段明确四个层次的目标。

第一层是业务目标。比如减少客服处理时长、提高游戏交互沉浸度、完成机器人操作任务、降低医疗信息分诊成本。

第二层是任务目标。比如生成答案、做出决策、执行动作、协调多个角色。

第三层是环境目标。比如在网页环境中调用工具，在三维空间中导航，在视频流中识别关键事件。

第四层是治理目标。比如不泄露隐私、不触发违规操作、不在高风险条件下越权执行。

这四层目标如果缺一，系统就容易偏。下面这张表可以作为目标定义的最小模板。

2.1.2 Agent 类型要尽早定性

李飞飞团队在分类章节里区分了具身智能体、行动智能体、交互式智能体、知识智能体、逻辑智能体、生成式智能体等。这种分类不是学术命名游戏，而是直接影响工程方案。问答型 Agent、执行型 Agent、协作型 Agent、具身型 Agent，它们在输入结构、动作空间、反馈机制和安全要求上差异很大。

为了避免后面频繁返工，项目初期应先完成类型定性。下面给出一个更适合工程讨论的简化分类。

类型一旦确定，后续许多争议会自然消失。比如问答型系统没必要上复杂的低层动作控制，具身型系统则不能只靠语言链路硬撑。

2.2 环境建模是 Agent 设计的起点

2.2.1 先画出状态空间，再谈能力

李飞飞团队对 Agent 的一个关键定义是“嵌入环境”。很多团队理解这句话时容易停留在概念层面，真正落到工程上，最核心的工作其实是状态空间建模。如果系统看见的状态不完整、不稳定、不一致，它后面的规划再聪明也没有意义。

状态空间至少要回答三个问题。系统此刻知道什么。系统需要知道但当前不知道什么。系统可以通过什么方式补齐缺失信息。这三个问题共同决定了感知模块、记忆模块与知识检索模块之间如何协作。

在不同环境里，状态空间形式差异很大。软件 Agent 看到的是页面 DOM、接口返回值、数据库状态和用户上下文。机器人看到的是图像、深度、姿态、接触点和物体关系。游戏 Agent 看到的是世界状态、角色位置、任务进度和其他智能体行为。医疗 Agent 则面对结构化记录、影像、文本病历、时间序列指标和合规约束。

下面给一个通用的环境建模清单。

2.2.2 动作空间必须精确定义

李飞飞团队在 Agent Transformer 讨论中提出，引入 agent token 的根本原因之一，是纯语言无法精确表达复杂动作空间。这个观点非常实用。很多失败的 Agent 项目，都不是败在理解任务，而是败在动作定义太模糊。比如“帮我处理这个工单”看似清楚，实际落到执行层，可能包含分类、检索、总结、回填、发送和记录多个步骤。每一步的执行条件、回滚方式和权限都不同。

动作空间定义至少包括四层内容。动作名称、动作参数、动作前置条件、动作后置验证。如果是高风险场景，还要加上确认策略和回滚策略。

下面给一个示意表。

动作空间一旦被形式化，规划模块、执行模块和治理模块之间才可能建立稳定接口。否则，所谓 Agent 规划很容易退化成自然语言建议。

2.3 边界条件要在设计早期锁定

2.3.1 高风险动作必须显式标出

李飞飞团队在医疗、机器人和监管讨论中反复强调，不可预测输出在现实场景中会造成严重问题。这意味着风险识别不能等系统快上线时再做。高风险动作必须在目标定义与环境建模阶段显式标出，并绑定执行策略。

可以用一个简化的风险分级模型来做初筛。

2.3.2 合规边界不是部署前补丁

李飞飞团队关于数据隐私、GDPR、CCPA、用户数据删除权的讨论，放在今天的 Agent 工程里有一个直接结论。**合规边界必须写进系统设计，而不是上线前补表单。**如果记忆模块从一开始就不区分敏感数据与普通上下文，后面再补匿名化几乎不可能彻底。若日志系统在初期就没有设计最小化记录，后面再清洗审计成本极高。

从工程角度看，合规边界至少要落到三个层面。数据采集边界、数据使用边界、数据保留边界。每个边界都要有明确的默认策略。

◆ 三、系统架构设计

3.1 为什么必须采用模块化架构

3.1.1 单体大模型无法承担完整 Agent 职责

李飞飞团队在论文中提出了一个非常清晰的五模块架构，包括环境与感知、学习、记忆、行动和认知。这套划分有很强的工程意义。它说明 Agent 的问题不是“模型够不够大”，而是“职责是否被合理拆分”。

单体大模型架构有三个典型缺陷。第一，状态不可控。模型内部表示很强，但外部无法稳定读取任务状态。第二，动作不可靠。复杂执行依赖低层控制与外部接口，纯语言生成缺乏约束。第三，反馈难积累。没有独立记忆与行为记录，系统无法形成可追踪的经验闭环。

所以，成熟的 Agent 架构通常至少包含六层。为了和前文保持一致，这里用更偏工程化的方式重述一遍。

3.1.2 模块划分不是为了优雅，而是为了稳定

有些团队会担心模块多了会让系统变复杂。这个担心只说对了一半。模块多确实增加实现复杂度，但不划分模块，复杂度并不会消失，只会被压进同一个黑盒里。黑盒在演示阶段不明显，一到长期运行环境，问题就会集中爆发。

模块化最大的收益有三个。**可替换、可观测、可治理。**感知模型可以升级，规划器可以更换，工具执行器可以独立测试，记忆策略可以按合规要求裁剪，治理策略可以针对场景独立加严。这些都建立在边界清晰的前提上。

3.2 一套可落地的参考架构

3.2.1 六层协同架构

下面给出一个适合多数企业 Agent 项目的简化参考架构。

这张图里有三个关键连接。

第一，记忆层同时服务感知与规划。感知不是一次性解析，它需要上下文才能理解当前输入。规划也一样，必须知道历史状态和先前执行结果。

第二，知识与工具层不直接替代认知层。检索、数据库、API、计算工具都是 Agent 的外部能力源，但由谁调用、何时调用、如何组合，仍然需要认知层来决策。

第三，治理层同时约束规划、执行与反馈。治理不是拦截器那么简单。很多错误在规划阶段就应被约束，而不是等执行后才报警。

3.2.2 高层规划与低层执行解耦

李飞飞团队在机器人章节中反复提到一个实践路线，利用大语言模型做高层任务规划，把低层动作控制交给专门控制器。这种思路在很多 Agent 场景里都适用。原因并不复杂。大模型擅长语义理解、子任务分解和常识推理，低层执行则需要精度、速度和确定性，两者优势并不重合。

一个实用的分层方式如下。

这样分层的好处是，推理自由度被留在高层，执行确定性被留在低层。中间层负责做约束映射，把开放式理解转成有限动作。工程上，这会大幅降低“模型说得很对，系统却做错了”的情况。

3.3 记忆系统是 Agent 稳定性的核心

3.3.1 没有记忆，就没有连续性

李飞飞团队在论文中提出“无限记忆智能体”的方向，这一表述虽然带有研究色彩，但传达的信息很明确。**没有记忆的 Agent，无法成为真正连续运行的系统。**很多所谓的 Agent 在每轮交互中都重新开始，只把最近几轮会话拼进上下文。这种方式对短任务尚可，对跨步骤、多状态、长周期任务几乎不够用。

记忆至少分三类。

第一类是会话记忆，保存当前任务上下文和最近动作。

第二类是情境记忆，保存环境状态、对象关系、角色信息和任务轨迹。

第三类是经验记忆，保存成功案例、失败样本、偏好反馈和策略修正记录。

这三类记忆不能简单混在一起。它们的数据结构、保留周期和调用频率不同。下面给出一个常见设计。

3.3.2 记忆的价值在检索，不在堆积

很多系统引入记忆后效果并不好，问题往往不在存不下来，而在取不出来。记忆系统真正的难点不在于保留，而在于按当前任务需要进行检索、压缩和注入。如果把大量历史信息无差别塞进提示词，系统只会更混乱。

比较稳妥的做法，是把记忆使用过程拆成四步。检索、筛选、总结、注入。即先按任务相关性召回，再按当前阶段筛掉无关内容，再将结果压缩为对决策有意义的结构化上下文，最后交给规划器。这样做，记忆才不会变成噪声。

◆ 四、知识融合与推理增强

4.1 幻觉问题为什么在 Agent 场景更严重

4.1.1 从回答错误到行为错误

李飞飞团队把幻觉分为内部幻觉和外部幻觉，这个分类对 Agent 很有启发。传统问答系统出现幻觉，问题主要是内容失真。Agent 出现幻觉，问题会直接扩展为行为失真。它不只是说错了，而是可能因此采取错误动作、调用错误工具、修改错误状态，甚至在高风险场景中造成实质损失。

这也是为什么论文特别强调，让模型嵌入真实环境有助于降低幻觉。原因不是环境本身让模型更聪明，而是环境提供了外部校验。没有外部校验，模型只能在参数记忆里“猜”。有了环境状态、检索证据和执行反馈，它就能在更小的误差空间里行动。

4.1.2 grounding 是 Agent 的第一能力增强机制

在实际工程里，grounding 可以理解为让决策建立在外部证据上，而不是仅建立在模型内部记忆上。这类证据包括环境状态、知识检索结果、视觉观测、系统返回值、规则约束和人工反馈。

下面这张表总结几类常用 grounding 手段。

4.2 知识增强的工程设计

4.2.1 隐性知识与显性知识要分工

李飞飞团队在知识智能体部分明确区分了隐性知识和显性知识。隐性知识主要来自大模型预训练，是广覆盖、弱可验证、时效受限的常识储备。显性知识来自数据库、知识库、文档系统和外部资源，是结构化、可追踪、可更新的信息源。

工程上，二者最合理的关系不是互相替代，而是职责分工。**隐性知识负责理解与推断，显性知识负责事实与依据。**如果让模型完全依赖显性知识，推理灵活性会下降。如果完全依赖隐性知识，事实可靠性又难保证。

可以用一张简单表格来划分职责。

4.2.2 RAG 不应只是“加个检索”

很多团队把知识增强理解成“把检索结果贴给模型”。这种做法在简单问答里有效，一进入 Agent 场景就显得粗糙。原因在于 Agent 的知识需求不是静态的，而是阶段性的。规划阶段需要目标相关知识，执行阶段需要参数与约束，修正阶段需要错误上下文和恢复策略。

所以，RAG 在 Agent 里更适合按步骤设计，而不是只做单次召回。一个更实用的链路通常包含以下几层。

4.3 推理增强要服务于执行

4.3.1 推理不是越长越好

李飞飞团队谈到推理增强时，列举了数据丰富化、算法增强、人在回路、实时反馈、跨领域迁移等多种方式。把这些内容转成工程语言，可以得到一个朴素但重要的判断。推理增强的价值不在于让模型“想得更多”，而在于让系统“做得更准”。

这意味着，推理设计不能只追求长链路解释。很多时候，过长的思维链反而会增加噪声和执行延迟。真正有效的推理，应当围绕三个目标组织。减少误判、提高行动选择质量、提升失败恢复效率。

4.3.2 可解释性应绑定关键决策点

论文在可解释性与监管部分提出，通过解释性文本和上层控制层可以帮助用户理解模型关注点。这一点在 Agent 场景里尤其必要。不是所有步骤都需要输出冗长解释，但关键决策点必须保留可追踪证据。

建议至少为以下节点设计解释记录。

这样的解释可以服务三类对象。研发用于排错，业务用于审核，用户用于建立信任。

◆ 五、训练与能力形成

5.1 Agent 的训练不能只靠一次微调

5.1.1 从“模型训练”转向“能力形成”

李飞飞团队在论文第四部分系统梳理了强化学习、模仿学习、上下文学习、传统视觉输入学习、预训练和微调等多种方法。把这些内容放回工程语境里，最重要的结论是，Agent 的能力不是通过单一路径训练出来的，而是在多种学习机制叠加下逐步形成的。

很多团队一开始容易把问题想得过于线性。先收一批数据，做一次指令微调，再补几个工具调用模板，系统似乎就具备了 Agent 能力。真正落地后很快会发现，这类能力非常脆弱。任务一旦拉长，环境一旦变化，用户表达一旦偏离样例，系统就失稳。原因并不复杂。问答微调形成的是局部输出能力，不是完整的行动能力。

Agent 至少需要形成四类能力。

第一类是理解能力。理解用户目标、任务上下文、环境状态和对象关系。

第二类是规划能力。把目标拆成步骤，并为每一步选择合适策略。

第三类是执行能力。把抽象规划映射成准确动作或工具调用。

第四类是修正能力。在失败、反馈、冲突和不确定条件下调整原有计划。

这四类能力通常不可能靠单一数据和单一训练方式全部覆盖。下面这张表可以帮助团队在训练设计阶段明确各方法的职责。

5.1.2 训练目标必须贴近运行形态

李飞飞团队在机器人与游戏场景的实验中反复强调一点，训练形态与运行形态越接近，最终落地效果越稳。这个判断对 Agent 特别重要。很多系统训练时只有“静态问答对”，上线后却要求它在开放环境中连续调用工具、维护状态并处理失败恢复。这样训练出来的系统，通常会在跨步骤任务里暴露出明显短板。

更合适的做法，是让训练样本尽量反映运行中的真实状态变化。比如不是只记录“用户问句—模型回答”，而是记录“初始状态—任务目标—步骤序列—工具回执—修正动作—最终结果”。这类样本虽然更难构建，但更接近 Agent 实际工作的轨迹。

5.2 组合式学习策略的工程组织

5.2.1 上下文学习适合启动，不适合承载长期能力

李飞飞团队在上下文学习部分指出，随着 GPT 类模型出现，少样本提示成为快速适配任务的重要方法。这类方法在 Agent 项目里价值很高，尤其适合冷启动。它的优势是快，几乎不需要训练周期，改提示即可试验新流程。

不过，上下文学习更像临时策略，而不是长期能力载体。原因在于，提示词可以快速改变表现，但无法真正改变模型的内在表示。复杂任务中一旦依赖大量提示工程，系统维护成本会迅速上升，且稳定性高度依赖上下文窗口与样例质量。

实际项目里，比较稳妥的路径通常是这样的。**先用上下文学习验证任务形态，再把稳定模式沉淀为微调数据、规则模板或执行器逻辑。**这样既能保留试验速度，也能避免后期全系统变成提示词拼图。

5.2.2 模仿学习适合形成基本动作策略

李飞飞团队在模仿学习部分提到，直接学习专家行为往往比纯探索更高效，尤其适合机器人与复杂交互任务。这个结论放到通用 Agent 设计里也成立。只要任务存在高质量专家轨迹，模仿学习几乎总是最划算的能力形成方式之一。

模仿学习最适合承担两类工作。一类是高频、重复、可示范的标准任务，比如常见工单流转、浏览器操作、游戏常规动作、机械臂基本抓取。另一类是需要遵守明确流程的任务，比如审批、配置、填报、质检。

它的局限也很清楚。如果环境变化很大、任务开放性很强，单纯模仿容易过拟合到示范轨迹，遇到新情况时不知如何调整。所以，模仿学习更适合作为“行为起点”，再配合反馈学习或强化学习补足泛化与修正能力。

5.2.3 强化学习不是必选项，但在长任务上很有价值

李飞飞团队对强化学习的总结比较平衡。它确实适合训练长期决策，但存在奖励设计难、数据效率低、长序列难学等问题。工程上不必把强化学习神化，但也不应简单排除。只要满足两个条件，它就非常有价值。

第一个条件是任务确实存在长链条依赖。例如导航、连续操作、多步博弈、多角色协作。第二个条件是系统能够拿到相对稳定的反馈信号。没有反馈，就没有可优化目标。

更现实的做法，通常不是让强化学习直接承担全部任务，而是让它聚焦在几个高价值的决策点上。比如子任务选择、路径选择、资源分配、失败恢复策略，而不是从输入到输出整条链路都由 RL 端到端学习。

5.3 数据设计比算法口号更重要

5.3.1 Agent 数据不只是“问答样本”

李飞飞团队在持续自我提升和基础模型生成数据部分提供了一个很重要的方向，Agent 的训练数据来源可以很丰富，不应局限于人工标注问答对。对工程团队来说，这几乎意味着一套新的数据观。

一个成熟的 Agent 数据体系，通常至少包含以下几类样本。

如果团队只积累问答样本，最终系统大概率只能得到“会表达的模型”，而不是“会行动的 Agent”。

5.3.2 模型生成数据是现实路径

李飞飞团队在第八部分讨论了基础模型生成数据的重要性，包括指令微调数据、视觉语言对和视频字幕等。对实际研发来说，这条路非常关键，因为高质量人工数据往往昂贵且稀缺，而强模型恰好可以成为数据生成器。

不过，这里有个容易被误判的地方。模型生成数据的价值，不在于数量本身，而在于结构质量。如果只是批量生成相似问答，价值有限。真正有价值的数据通常具备三个特点。贴近任务结构、包含中间状态、可与外部反馈对齐。

例如，一个工具型 Agent 的优质训练样本，不只是“用户意图—最终答案”，而应包括任务理解、参数生成、调用工具、接收回执、错误处理和最终落地结果。这样产生的数据才能真正服务于 Agent 的执行链路。

5.4 从模拟到现实的迁移不能省略

5.4.1 Sim-to-Real 是具身 Agent 的工程门槛

李飞飞团队在跨现实与 sim-to-real 部分总结了领域随机化、领域自适应、改进模拟器等路径。这部分内容对机器人、虚拟角色、导航 Agent 都有直接价值。很多团队在模拟器里训出不错的结果，一到现实环境就明显退化，问题根源通常就在迁移阶段。

模拟环境的问题有两个。一个是视觉差异，一个是物理差异。视觉差异包括光照、纹理、噪声、视角变化。物理差异包括摩擦、碰撞、延迟、传感器误差和环境扰动。只要这些差异没有被训练阶段吸收，现实运行就会出现明显断层。

5.4.2 迁移策略要从一开始进入训练设计

比较稳妥的做法，不是等系统快上线再考虑迁移，而是在训练方案里提前植入。领域随机化就是典型例子。通过在训练时随机扰动物体外观、场景参数和环境条件，可以让策略学会对变化保持鲁棒。类似地，小规模真实数据配合模拟大数据做领域自适应，也是成本与效果比较均衡的办法。

◆ 六、测试与验证

6.1 Agent 评估必须是系统评估

6.1.1 不能只看单轮正确率

李飞飞团队在多个应用章节以及数据集章节里都强调了 benchmark 和评估的重要性。放到工程上，一个核心结论非常明确。评估 Agent，不能只看单轮回答对不对，而要看系统能不能稳定完成任务。

很多项目在离线问答指标上表现不错，但一到连续任务里就不行。原因在于，Agent 的错误往往不是一个时刻发生，而是在一连串局部决策中逐步积累。单轮正确率反映的是局部能力，无法反映长期状态维护、动作一致性和失败恢复能力。

所以，Agent 的评估维度至少应覆盖五个方面。

6.1.2 指标要贴近业务闭环

一个常见误区是，评测指标太抽象，和真实业务断开。比如只看 BLEU、Rouge 或通用正确率，无法反映系统上线后的真实价值。更合适的做法，是把通用指标和业务闭环指标结合起来。

举例来说，一个企业内部自动化 Agent 的核心指标，可能更应包括流程成功率、平均完成时长、人工介入率、失败恢复率、重复调用率等。一个机器人 Agent，重点可能转向抓取成功率、路径有效率、碰撞率、异常停车率。一个知识型 Agent，则会更关注引用命中率、事实一致率、问题解决率。

6.2 测试集要覆盖正常、异常与对抗三种条件

6.2.1 正常样本只证明“能跑”，异常样本才证明“能用”

李飞飞团队在文章中讨论了零样本、少样本、未知环境、未见场景等问题，这些都指向同一个工程事实。只用正常样本测试，得到的不是可靠性，而只是理想条件下的可运行性。

Agent 的测试集至少应覆盖三类样本。

第一类是正常样本，用来确认系统在标准流程下能按预期工作。

第二类是异常样本，包括缺字段、错字段、模糊表达、中途状态变化、工具超时、知识冲突、权限不足等情况，用来验证恢复能力。

第三类是对抗样本，包括诱导越权、伪造上下文、触发偏见、混淆对象引用等情况，用来验证安全边界。

下面给出一个评测集设计表。

6.2.2 红队测试是 Agent 的必要环节

李飞飞团队在持续学习部分专门提到红队测试的价值。对 Agent 来说，红队测试不只是安全附加项，而是能力迭代的重要来源。因为很多边界问题，不在正常使用中暴露，而只会在极端提示、错误链路和对抗输入下出现。

红队测试的目标不是证明系统安全，而是系统化地暴露脆弱点。暴露出来之后，再把这些脆弱点转成训练数据、规则补丁和执行约束。只有这样，红队测试才真正进入生命周期，而不是停留在合规动作层面。

6.3 验证体系要把离线、在线和人工评估结合起来

6.3.1 离线评估负责定位，在线评估负责验证

离线评估的优势是可控、可重复、成本低，适合快速定位问题。在线评估的价值在于，它能反映真实用户和真实环境中的行为表现。两者缺一不可。

一个稳妥的实践方式是这样的。先通过离线评估筛掉明显不稳定的版本，再在灰度环境里观察真实任务完成情况、人工接管比例和异常事件分布，最后再决定是否扩大开放范围。

6.3.2 人工评审仍然不能被省略

李飞飞团队在多模态、游戏和医疗部分都提到了人类评审的重要性。这在 Agent 项目里依旧成立。因为很多问题不是简单的对错，而是任务适配性、解释合理性、动作自然度和风险边界是否合适。这些维度目前仍然离不开人工评估。

◆ 七、部署与运行控制

7.1 Agent 上线不是终点，而是控制开始

7.1.1 受控部署比“全能上线”更现实

李飞飞团队在机器人和监管部分明确指出，大模型黑箱性质在物理场景中风险更高，因此需要预执行验证与人类控制层。这个原则放在所有 Agent 场景里都成立。上线的关键，不是尽快放开全部能力，而是以受控方式逐层开放。

比较常见的部署策略是分级开放。

这种分阶段上线方式的好处，是能在不牺牲安全的前提下，逐步积累真实运行数据。

7.1.2 权限管理必须跟动作空间绑定

部署阶段最常见的治理失误，是权限管理做得过粗。比如只判断“这个 Agent 能不能访问系统”，而不是判断“它能不能在当前状态下执行这个动作”。李飞飞团队对高风险行为的讨论，本质上要求权限控制做到动作级、对象级和上下文级。

换句话说，权限不是一个布尔值，而是一组带条件的执行约束。谁触发、在什么场景、对什么对象、执行什么动作、是否需要确认，这些都要写进控制逻辑。

7.2 监控、日志与回滚是运行期基本盘

7.2.1 没有日志，就没有 Agent 运维

传统应用的日志主要服务故障排查。Agent 的日志要求更高，因为它不仅要记录系统故障，还要记录决策轨迹。没有决策轨迹，研发团队无法复盘为什么选了这个工具、为什么进入这条路径、为什么没有触发风险拦截。

建议至少记录以下几类日志。

7.2.2 回滚机制决定系统是否可运维

很多团队重视执行，不够重视回滚。实际运行中，真正决定系统可运维性的，往往不是它能做多少事，而是出错后能否快速回到安全状态。对 Agent 来说，回滚至少应覆盖三层。状态回滚、动作回滚、版本回滚。状态回滚保证任务上下文恢复，动作回滚保证外部影响可撤销，版本回滚保证新策略出问题时能退回旧版本。

◆ 八、持续进化与自我提升

8.1 Agent 的长期价值来自运行中学习

8.1.1 真正稀缺的数据在线上

李飞飞团队在论文第八部分指出，未来 Agent 的关键方向之一，是利用人类交互数据和基础模型生成数据持续优化自身。这个判断非常重要。因为离线训练能解决的是“已知任务”，而线上运行会不断暴露“未知问题”。这些未知问题，恰恰是最有价值的数据来源。

一个成熟的 Agent 项目，应该建立从线上到训练的回流管道。回流内容不只是失败样本，还包括部分成功但效率不高的轨迹、用户主动修正的信息、工具超时记录、人工接管原因、红队触发路径等。

8.1.2 数据回流要形成稳定机制

很多团队也会收集日志，但日志和训练数据之间没有稳定映射，最后只能停留在排错层。要让 Agent 真正持续进化，必须建立数据回流机制，把运行信息标准化成可训练样本。

下面给一个简化流程。

8.2 模型蒸馏与能力下放是现实路线

8.2.1 强模型负责探索，小模型负责承载

李飞飞团队提到，强基础模型可以用于生成训练数据，再反哺较小模型。这条路线在企业场景里非常现实。强模型适合探索复杂行为模式，小模型更适合稳定承载、低成本部署和私有化运行。

这意味着团队在能力建设上可以采取“双层模型策略”。先用强模型做高自由度试验，收集高质量轨迹和决策模式，再将稳定模式蒸馏到专用 Agent 模型或专用执行器上。这样既能利用强模型的上限，又不必长期承担高成本和高不确定性。

8.3 版本迭代要有清晰节奏

持续进化不等于频繁上线。真正稳定的 Agent 迭代，应遵循一个清晰节奏。收集问题、归因分析、修复方案、离线验证、灰度上线、运行观察、版本固化。只要跳过中间某一步，后续就容易进入“越修越乱”的状态。

◆ 九、伦理、安全与合规治理

9.1 治理不是补充项，而是系统属性

9.1.1 幻觉、偏差、隐私问题会在 Agent 里被放大

李飞飞团队在论文第二部分以及后面的伦理章节里，对幻觉、偏差、数据隐私、解释性和监管做了比较系统的讨论。对 Agent 项目来说，这些问题比传统问答系统更严峻。原因很直接。问答模型出错，多数时候停留在表达层。Agent 出错，可能直接影响环境状态、流程结果和外部对象。

所以，治理绝不能只理解成“输出安全过滤”。它应覆盖目标定义、训练数据、记忆系统、权限模型、执行链路、日志审计和持续学习。

9.1.2 治理要做成默认能力

比较成熟的治理设计，通常会把下列机制直接内嵌到系统里。

9.2 包容性与公平性要落到数据和交互细节

李飞飞团队在偏差与包容性一节中用了较大篇幅说明训练数据中的文化、语言和历史偏见问题。把这一点转成工程动作，重点不在写一份宏观原则，而在于审查数据来源、检查任务场景，并修复交互设计中的默认偏向。

比如，多语言系统是否只在英文语料上训练核心策略。医疗 Agent 是否对少数群体表达方式支持不足。视觉系统是否对特定人群或场景识别偏差明显。解决这些问题，离不开数据分布审查和针对性测试。

9.3 合规能力要成为基础设施的一部分

李飞飞团队提到 GDPR、CCPA 和被遗忘权等要求，这对 Agent 平台设计有一个直接启发。**合规能力最好做成平台级基础设施，而不是项目级手工处理。**例如统一的数据脱敏服务、统一的日志留存策略、统一的用户数据删除接口、统一的审计检索系统。只有做到基础设施层，团队规模一大时才不会失控。

◆ 十、十条核心原则的工程化落地

前面各阶段展开较多，这里把方法论再次压缩成十条原则，并补充它们在工程中的直接含义。

10.1 目标先于模型

先定义业务目标、任务目标和治理目标，再选技术栈。没有清晰目标，强模型也会被用成高成本聊天接口。

10.2 环境先于能力

先定义状态空间、动作空间和反馈机制，再讨论能力组合。Agent 的价值来自在环境中行动，而不是脱离环境展示推理。

10.3 模块化优于单体化

系统职责要拆清楚。感知、记忆、认知、执行、学习、治理各自独立，彼此协作，后续才能可替换、可观测、可治理。

10.4 多模态优于单模态

只靠文本的 Agent 很难稳定理解真实世界。视觉、音频、状态流和上下文结构化信息，决定了系统是否真正接地。

10.5 grounding 优于纯生成

外部知识、环境证据、工具返回值和执行反馈，是抑制幻觉的关键来源。生成能力再强，没有 grounding 也难以稳定行动。

10.6 闭环优于单轮

Agent 的核心机制不是回答一次问题，而是在持续感知、规划、执行和修正中推进任务。这决定了系统设计必须围绕闭环展开。

10.7 组合学习优于单一路径

预训练、微调、提示学习、模仿学习、强化学习、人类反馈学习，各自解决不同能力层的问题，不能互相替代。

10.8 评估优于演示

漂亮演示不代表可落地。真正的 Agent 需要穿过系统化评测、异常测试、红队测试和灰度运行的检验。

10.9 演进优于静态

上线之后的数据才是最有价值的数据。没有数据回流、版本迭代和持续优化，Agent 只会在现实环境中不断老化。

10.10 治理内建而非外挂

安全、伦理、隐私、合规不能靠补丁解决，必须写进架构、训练、部署和运维流程里。

结论

李飞飞团队在《智能体：探究多模态交互的发展前景》中所讨论的，并不只是下一代模型形态，更是一种新的系统观。它提醒我们，AI 的重心正在从静态知识处理转向面向环境的动态行动。从这个角度看，AI Agent 的核心问题并不是模型是否足够强，而是系统是否真正具备环境感知、知识 grounding、结构化记忆、任务规划、动作执行、反馈修正和长期治理能力。

把这套判断落到工程实践中，意味着 Agent 设计不应再停留在“模型接工具”的浅层封装，而要回到系统工程。目标定义决定方向，环境建模决定边界，架构设计决定可维护性，知识融合决定可靠性，训练机制决定能力形成，测试体系决定上线质量，部署控制决定风险水平，持续进化决定长期价值，治理机制决定系统是否能够被信任。

对未来一段时间的 Agent 建设来说，最值得警惕的，不是能力不够，而是误把局部能力当成完整系统。真正成熟的 Agent，不会只在演示里显得聪明，而会在复杂环境里保持稳定、克制、可解释和可演进。这也是李飞飞团队这篇论文最重要的现实意义。它把讨论重新拉回到智能系统本身，而不是停留在模型表面的繁荣。

📢💻 【省心锐评】

Agent 不缺概念，缺的是把目标、环境、知识、执行、反馈和治理真正接成闭环的系统工程能力。