2022年底，当ChatGPT第一次出现在大众面前时，人们对它的印象是一个“很会聊天的AI”。你问它一个问题，它给你一个回答。这个交互模式简单而纯粹：输入文本，输出文本。
但是，很快，一个想法在开发者社区中蔓延开来：如果让这个“很会聊天的AI”不仅能回答问题，还能做事情呢？比如，不是问它“北京明天的天气怎么样”，而是让它“帮我查一下北京明天的天气，如果下雨就提醒我带伞”。后者需要的不仅是知识，还需要行动——调用一个天气查询工具，根据结果做出判断，再给出建议。
这就是AI Agent的起点：从一个只会“说”的模型，到一个能“做”的智能体。
要理解Agent，首先需要理解它依托的基础——大语言模型（Large Language Model，LLM）。
LLM的核心能力是预测下一个token。经过海量数据的训练，这个看似简单的任务让模型涌现出了惊人的能力：理解语义、推理逻辑、生成代码、翻译语言、撰写文章。这些能力构成了Agent的认知基础。
但LLM有一个根本性的局限：它被困在训练数据的时间窗口里，且无法与外部世界交互。
你问它“今天北京的天气如何”，它不知道。因为“今天”的数据不在它的训练集中。
你让它“帮我把这封邮件发给张三”，它做不到。因为它没有发送邮件的“手”。
你要求它“查一下我们公司上季度的销售数据”，它无能为力。因为你的数据库在它的知识范围之外。
LLM像一个知识渊博但被关在图书馆里的学者——他什么都知道一点，但既看不到外面的世界，也无法动手做任何事。
Agent的核心思想，就是给这个学者装上眼睛和手，让他走出图书馆。
AI Agent（人工智能体）是一个以LLM为核心、能够感知环境、做出决策、执行行动的系统。它的本质是一个循环：
感知（Perceive）
· 接收用户输入
· 获取工具返回结果
· 读取记忆中的上下文
│
▼
思考（Think）
· 理解当前状态
· 推理下一步该做什么
· 决定调用哪个工具
│
▼
行动（Act）
· 调用工具/API
· 生成给用户的回复
· 更新记忆
│
└──────────► 循环
用更通俗的话说，Agent就是一个会自己“想办法”的AI。你给它一个目标，它自己拆解步骤、选择工具、执行操作、检查结果，并在必要时调整策略。
举个例子，当你对一个Agent说“帮我订一张下周五去上海的机票”时，它可能会：
思考：我需要知道出发地、预算、时间偏好。用户没说出发地，我应该问，或者从记忆中找。
行动：调用日历工具确认下周五的日期；调用机票查询工具搜索航班。
感知：收到查询结果，发现下午的航班比上午便宜30%。
再思考：用户没有指定时间，我倾向于推荐性价比高的选项，但需要用户确认。
再行动：向用户展示推荐方案，等待确认后调用订票工具完成购买。
这一系列行为的核心特征是：不是用户告诉它每一步怎么做，而是它自己决定怎么做。
你可能会问：这不就是一个带工具调用的聊天机器人吗？两者之间的界限确实模糊，但有一个关键的区分维度：自主性（Autonomy）。
| 维度 | LLM聊天应用 | AI Agent |
|---|---|---|
| 交互轮次 | 一问一答 | 多轮自主循环 |
| 工具使用 | 用户指定或简单触发 | Agent自主选择与组合 |
| 任务粒度 | 单一步骤 | 多步骤的完整目标 |
| 决策权 | 用户主导 | Agent在约束内自主决策 |
| 失败处理 | 返回错误信息 | 尝试重试、换策略、反思修正 |
| 状态管理 | 无或简单 | 持续追踪任务进度 |
一个实用的判断标准是：如果你把用户从循环中拿走，系统还能不能继续推进任务？
聊天应用：用户问 → AI答 → 用户再问 → AI再答。拿走用户，系统停滞。
Agent：用户给目标 → Agent执行（可能中途问用户，也可能不问）→ 完成目标。拿走用户（在允许的范围内），系统仍能推进。
当然，自主性是程度问题，不是非此即彼。现在的Agent自主性是有限的，而且在实际应用中，我们往往故意限制它的自主性——比如涉及支付时必须人工确认。本书后面会反复讨论这个权衡。
一个关键转折：Function Calling 从技术角度看，Agent的爆发有一个关键的转折点：Function Calling（工具调用）能力的出现。
2023年6月，OpenAI在GPT-4上推出了Function Calling：模型不仅能生成文本，还能输出一个结构化的函数调用请求，指定要调用的函数名和参数。
这意味着什么？在此之前，让LLM“做事情”是极其别扭的——你需要设计复杂的Prompt诱导模型输出特定格式的文本，然后用正则表达式去解析这个文本，稍有不慎就解析失败。
Function Calling让这件事变成了模型的原生能力：
{
"tool_call": {
"name": "get_weather",
"arguments": {
"city": "北京",
"date": "2026-08-25"
}
}
}
模型不再“模拟”调用工具，而是真正输出一个可执行的调用指令。这就像给学者装上了一个标准的“手部接口”——从此以后，只要能连接到这个接口的工具，他都能用。
随后，Claude、Gemini、Llama等主流模型都跟进提供了类似能力。工具调用的标准化，是Agent从理论走向工程实践的基石。
你可能会想：AI Agent这个概念并不新，早在上世纪就有了“智能体”的研究。为什么现在才火起来？
答案是三个条件的成熟：
第一，推理能力的质变。 早期的语言模型也能“调用工具”，但它们不理解什么时候该调用、调用后如何解读结果。GPT-4及后续模型的推理能力，让Agent能够处理“查询失败后怎么办”“用户信息不完整时该问什么”这类需要判断力的场景。
第二，工具生态的标准化。 Function Calling让工具接入变得简单，MCP（Model Context Protocol）进一步标准化了工具的定义方式。现在，一个工具写好一次，就能被任何支持该协议的Agent使用。
第三，工程基础设施的跟进。 这正是本书的主题——Harness。Agent的能力需要被评估、调试、监控和治理，而这些基础设施在过去两年里逐渐成熟，让Agent从实验室走向生产环境。
让我们用一个完整的例子来结束本节。这个例子贯穿了一个简单Agent的完整“思考”过程。
用户输入：“帮我看看我们公司官网的博客，最近哪篇文章最受欢迎，然后给这篇文章的作者发一封祝贺邮件。”
Agent的内部过程：
【思考 1】
用户想要两件事：① 找出最受欢迎的博客文章；② 给作者发邮件。
我需要先获取博客数据。我有两个工具可用：get_blog_posts（获取文章列表）、
get_post_stats（获取单篇文章的统计数据）。
计划：先获取文章列表，然后查每篇的访问量，找最高的那篇。
【行动 1】
调用 get_blog_posts() → 返回 15 篇文章的元数据（标题、作者、发布日期）
【思考 2】
拿到15篇文章，但还没有访问量数据。逐一调用 get_post_stats 会比较慢，
但这是我的工具限制。先查最近30天的文章（5篇），因为“最近最受欢迎”
更可能在这些文章中。
【行动 2】
并行调用 get_post_stats(post_id="101")、get_post_stats(post_id="102")...
→ 返回各篇的访问量、阅读时长、分享数
【思考 3】
文章《我们如何重构了支付系统》的访问量最高（12,450次），
作者是“张三”。用户说“给作者发邮件”，但没有提供具体邮件内容。
我应该起草一封得体的祝贺邮件，发送前让用户确认（因为发邮件是有副作用的操作）。
【行动 3】
调用 send_email(to="zhangsan@company.com", subject="恭喜！您的文章成为本月最受欢迎内容",
body="...")
→ 但在此之前，先向用户展示草稿，等待确认。
【向用户输出】
“我已找到最受欢迎的文章：《我们如何重构了支付系统》（访问量12,450次）。
作者是张三。我起草了一封祝贺邮件，请确认是否发送：[邮件预览]”
这个过程中值得注意的几点：
Agent自己决定了执行策略（先查列表，再筛近期文章，最后查统计）。
Agent在面对副作用操作时选择了谨慎（发邮件前请求确认）。
Agent识别到了信息缺口（用户没给邮件内容），并主动生成了方案。
这些行为背后没有一条是用户手把手教的。这就是Agent与普通程序最本质的区别：它在约束范围内做出了自己的判断。
AI Agent是以LLM为核心、能够在环境中自主感知、决策和行动的系统。它源于LLM的推理能力，通过Function Calling获得了“行动”的能力，在Harness的支撑下走向工程化落地。
理解Agent的关键不在于记住某个定义，而在于理解自主性的光谱——从固定工作流到全自主智能体，每一级都对应着不同的工程挑战和信任要求。
在下一节中，我们将讨论为什么Agent需要Harness——即为什么“会动的AI”还需要一套“操作系统”来确保它的行为可靠、可评估、可治理。