半年 Agent 产品实践：24 个关键词的工程理解
从三月份开始做 Agent 产品，到现在差不多半年。从最初的概念模糊到如今的一知半解，我对 Agent 的理解越来越具体。
最开始以为 Agent 就是 LLM 加一些提示词和工具，真正做下来发现这只是其中一部分。工具调用、上下文管理、记忆系统、Agent 评测，这些都是必须处理的问题。
学习一个行业最快捷的方式是了解这个行业的关键词，Agent 领域也不例外。下面把这半年做 Agent 产品遇到的行业关键词和个人理解整理一下，内容主要来自实际做产品的体会，部分表述未必完全准确，意思到位即可。
1、LLM：大语言模型
核心能力是根据已有上下文推测下一个内容。从叫法可以看出，最原始的形态是纯粹的文字，根据文字预测文字。
经过这两年的发展，很多大语言模型已不只支持文字，图片、视频、音频等也逐渐支持，但叫法保留了下来，没有严格划分。生图模型、语音模型、视频模型等还有很多细分，这里不赘述。
2、多模态：模型支持多种类型的信息
模型不仅支持文字，还支持图片、视频等，称为多模态模型。
从输入和输出角度看，多模态分两种：输入多模态和输出多模态，顾名思义。
从训练角度讲，又分为原生多模态和非原生多模态。原生多模态是模型直接理解信息本身——比如一段人说话的音频，原生多模态直接理解这段音频，处理说话内容，还可能感知说话的语气、音量。
非原生多模态可能是内部有个语音转文字模型，文字再给大语言模型。外部看起来输入的都是音频，但内部机制上，原生多模态直接理解信息本身，通常保留更多信息。
非原生多模态的优势在于每个模块可以单独替换，针对特定场景为每一部分选择特定模型。两者没有绝对优劣，更多是看场景，综合速度、价格、能力等选择。
3、流式输出/非流式输出
分别表示"生成什么就马上发什么"和"全部输出完再发出来"。
比如语音转文字模型，流式输出时一直听你说，边说边转文字；非流式输出则等你说完，再把整段音频转成文字。
4、Agent
Agent 常和 LLM 放在一起理解。LLM 只能说，但不能干活，Agent 则能真正干活。
举例：问 21 年到 25 年黄金价格变化，LLM 的回答基于内部数据知识直接给出；Agent 则会调用相关工具，去真实网页或其它地方查询，更聪明的 Agent 可能多渠道对比，把不同地方的价格都给你。
5、Function Calling
LLM 表达自己想要使用工具的过程就是 Function Calling。模型输出一段结构化内容，外部程序收到后就真的去执行。
6、Tool Use
Tool Use 让模型的意图变成真实的行动。LLM 表达了工具调用意图，Agent 系统负责让工具真正用起来。这就是为什么说 LLM 是大脑，Agent 才是能真正干活的员工。
7、ReAct：Reasoning + Acting
Tool Use 决定模型能不能用外部工具完成任务，ReAct 则表示模型如何一步步做决策、使用合适工具、完成任务的过程。
ReAct 是思考、决策、行动、拿到结果、分析结果、继续思考、决策、行动……根据结果优化步骤进行下一步。相比纯粹的思考后直接给结果，中间多了纠错的可能。
但它不一定完全可靠，有时也会出错。通常会有限制：某些工具的权限、超时机制、重试次数、最大行动次数。
8、可打断性：Interruptibility
做 Agent 产品时发现，能不能打断、中途用户能不能插话，非常影响用户体验。
很多时候用户没有能力把事情一次性想清楚——内容发出去了又想到一部分；看到 Agent 开始干活有了想法需要插话；发现 Agent 做错了让他别做了。这些都是需要插话的场景。
Codex 和 Claude Code 目前做得还行，中间插话被叫做"引导"。最近比较火的 Workbuddy 和豆包工作台似乎不支持。
9、MCP：Model Context Protocol，模型上下文协议
MCP 解决 AI 产品怎么和外部服务、上下文、能力等进行连接的问题。
在此之前，每个 AI 应用都要为每个外部应用单独开发接入方式。有了 MCP，外部应用直接提供一个统一接口，AI 应用按这个接口就能接入对应能力。
比如淘宝 MCP 有统一的接口和请求方式，Agent 产品通过这个标准接口就能调用淘宝相关工具和能力。有 MCP 的外部服务不需要自己再写工具——MCP 接口告诉你提供哪些工具、如何发起调用、如何接受结果，直接使用即可。
但如果人家的 MCP 没有提供某些工具或数据，而你又需要，就得自己写工具想办法获取了。
10、Skill
不严格来说，Skill 就是一段提示词，告诉模型某任务分几步做什么、怎么用工具。
这对只有一个孤零零的 Skill.md 文件的 Skill 成立，但很多 Skill 还有自己特有的工具。大多数 Skill 针对某一类反复出现的场景，把相关流程写清楚，启动条件、操作说明等固定下来，能极大节省人力。
11、Workflow：工作流
Agent 是能自主决定、自主干活的系统。Skill 是经验沉淀——Agent 看到后知道这样干活可能更好，但可能自己找到更好的路，不一定按 Skill 来，自主性高。
Workflow 则是描述相对固定的流程：这步输入是什么、什么格式、输出是什么、失败了怎么处理，大部分情况都考虑到了，自主性较差。
Agent 和 workflow 不是非此即彼，大多数时候混合使用，以达到更好效果。
12、Agent Runtime
Agent 持续运行需要的基础设施，管理模型调用、工具使用以及各种状态处理的系统，让 Agent 能正常稳定地运行。
13、HITL：Human in the Loop，人在回路
HITL 即人工介入。Agent 干活不能闷头干到底，有些东西需要人介入确认，有些事情必须人来做。
14、Sandbox：沙箱
沙箱是 Agent 受限制的运行环境。在范围内干活，即使出问题，也尽量降低对用户的影响。
15、Artifact
Artifact 是 Agent 交付给你的东西。Claude 桌面 App 最近比较烦——每次让它生成 demo 文件，它都要调用 artifact 相关 skill，然后生成一个 claude.ai/artifact/^ 的链接。我只要本地的，每次都得提醒。
16、Memory：记忆
模型没有记忆，每次输出都是全新结果。所谓记忆，其实是过往运行保留在模型外部的内容。
每次模型的输入除了用户给的，还有系统保留的一堆内容，经过处理后一起输入。输入足够丰富全面，输出就成了懂你的样子。
17、Context Window：上下文窗口
模型一次能处理的上下文长度，现在比较常见的是百万上下文级别。
18、上下文压缩
模型上下文有限，单轮交流太长，模型就会记不住之前说过什么。上下文压缩是根据需要删除一些内容，留下更有用的部分，保证当前任务不断线，让 Agent 能继续工作。
上下文压缩的方法很多，不同 Agent 系统不一样。
19、Prompt Engineering：提示词工程
之前还有"提示词工程师"的说法，现在已听不到了，但提示词工程仍然存在。虽然模型很强大，但依旧需要研究怎么写，模型才更容易理解。
20、Context Engineering：上下文工程
每次调用模型时，组织能让模型更好完成任务所需的信息，包括但不限于记忆、工具描述、权限信息、用户需求等。
21、Sub-Agent
个人感觉未来一个 Agent 就够了，为什么还要分成多个？现在的 Sub-Agent 也许只是权益之计——上下文窗口不够、模型能力不足等原因导致。
Sub-Agent 的设计核心是清晰的边界：某个 Agent 处理某一类任务，配备一些通用的工具，权限划分好。
22、Evals：评测
Agent 的重要特点就是工作过程不确定，输出结果也不确定，所以产品研发中做好评测很重要。
评测一般看两部分：首先是结果——标准任务看有没有完成，非标准任务看结果质量；其次看完成任务的过程——调用工具、步数、时间、模型开销等。
比如一个购物 Agent，它有自己的工具，每一步有各种前进方式。评测就看它有没有调用相关工具打开对应网页、点击/滚动方式对不对、几次才成功、失败了怎么处理、付款页面怎么解决、敏感操作怎么处理。然后分析整个过程，该优化工具的优化工具，该优化提示词的优化提示词。评测驱动开发，继续评测，不断提升 Agent 效果。
23、Benchmark
Benchmark 大概就是统一测试，大家同台竞技用同一套标准评测，得分高就是你强。
24、Computer Use
最近 Codex 的 Computer Use 比较火。这个方向潜力蛮大——可能很长一段时间很多 App 都没有接口，Computer Use 以视觉理解的方式就成了 Agent 控制 App 的重要途径。
对应的还有 Phone Use 和 Browser Use。这三个能力是重点方向：大多数互联网底层还是太封闭，视觉是重要的通用路径，可以覆盖很多没有接口的场景。
以上是 Agent 领域的关键词中和我实际产品经验最相关的一部分。这些词肯定不是全部，有些理解也不完全准确，但通过这些词基本能看出一个 Agent 产品是怎么从模型变成真正能干活系统的。AI 领域发展很快，有些现在时髦的东西半年后就未必重要了。我对 Agent 的理解也在变化中，继续做，继续踩坑。