一文读懂 AI Agent：从模型到智能体系统

agent-">一、核心定义：Agent 是系统，不是模型

在讨论任何细节之前，先把最重要的一句话讲清楚：AI Agent（智能体）是一个以大模型为核心，能够调用外部工具、接收执行反馈，并持续完成任务直至目标达成的系统。

这句话中最关键的词，不是“大模型”，也不是“调用工具”，而是“持续完成任务”。它划清了 Agent 与普通模型调用之间的界限：

• 模型是“一次问答”：输入一段提示词，输出一段文本，调用即结束。过程中既不能感知外部世界的变化，也无法修正自己的行为。
• Agent 是“一个循环”：给定一个目标后，它会自主拆解任务、选择工具、执行动作、观察结果、修正计划，循环往复，直到目标完成或触发终止条件。

用一段简化的伪代码表示 Agent 的本质骨架：

goal    = 用户目标
history = []
while 未达成(goal) 且 未超过循环上限:
    thought = model.推理(goal, history)   # 思考：下一步做什么
    action  = 选择动作(thought)            # 规划：调用哪个工具或技能
    result  = harness.执行(action)         # 行动：真正与外界交互
    history.append(action, result)         # 观察：把反馈写回上下文
return 汇总输出(history)

可以看到，模型只出现在“推理”这一行；真正让这段代码成为 Agent 的，是外层那个循环——目标管理、动作执行、反馈写入、终止判断，全部由“系统”承担。换句话说：模型是大脑，Agent 是完整的生命体。

二、背景与价值：为什么会出现 Agent

1. 大模型自身的三个局限

第一，知识是静态的。模型的知识来自训练语料，训练结束后便与世界脱钩，无法获取最新信息，也不知道企业内部的私有数据。第二，能力是被动的。模型只能生成文本，不能真正“做事”：无法查询数据库、无法调用接口、无法修改文件——它可以告诉你怎么订机票，但它自己订不了。第三，交互是无状态的。每次调用相互独立，模型本身不记得上一轮做了什么，更不具备跨会话推进任务的能力。

2. 传统自动化的局限

另一条路线是传统流程自动化：把每一步操作硬编码进脚本或流程引擎。这类方案确定性强，但极度脆弱——一旦页面改版、接口变更、流程出现新分支，就需要人工重新编排；而且它没有“理解”能力，无法处理事先没考虑过的情形。

3. Agent 填补的空白

Agent 的出现，本质上是把两者的长处结合：用大模型承担“理解、规划与决策”这类非结构化的智力工作，用工具与流程承担“执行”这类确定性工作，再用一个运行框架把两者粘合成可持续运转的闭环。这就是“系统”的价值：单看每个组件都不新鲜，组合之后才产生“自主完成任务”这一质变。

三、核心组成：从 Model 到 Harness 的六层拆解

一套工程化的 Agent 系统，通常可拆解为六个层次。这六个词描述的是职责分层，而非某个具体产品。

1. Model：推理引擎

Model 是 Agent 的大脑，负责自然语言理解、任务规划、推理判断与内容生成，决定了 Agent 智能水平的上限——模型推理能力不足，再多的工具和流程也无法弥补。工程上，Model 层应当设计为“可替换”：通过统一的调用接口对接不同模型，按任务复杂度、成本与延迟要求灵活选择，而不是把系统绑死在某一个模型上。

2. Tool：与外部世界交互的“手”

Tool 是 Agent 感知和改变世界的通道，通常以结构化的函数描述暴露给模型，由模型决定何时调用、传什么参数。常见类别包括：

• 信息获取类：联网搜索、知识库检索、数据库查询；
• 操作执行类：文件读写、代码执行、发送消息、调用业务接口；
• 计算处理类：数值计算、图表渲染、格式转换。

业界普遍通过“函数调用”机制实现：开发者向模型声明每个工具的名称、用途与参数结构，模型在推理时输出结构化的调用请求，由系统代为执行并回传结果。工具声明写得越清晰，模型的选择就越准确。

3. Skill：把“会用工具”升级为“会做事”

只有工具还不够。工具是原子化的，好比给了模型一把锤子、一把螺丝刀；而 Skill 是把工具连同步骤、判断标准与领域知识封装成“方法论”。例如“联网调研并输出报告”是一项技能，内部可能包含确定检索关键词、调用搜索、抓取清洗内容、交叉验证来源、按模板汇总输出等多个步骤。这些步骤若不封装，模型每次都要现想流程，质量不稳定；封装成 Skill 后，Agent 遇到同类任务即可复用成熟路径，输出质量和执行效率都会显著提升。一句话概括：Tool 解决“能不能做到”，Skill 解决“做得好不好、稳不稳定”。

4. Rules：行为的边界

Rules 定义 Agent“必须做什么、不能做什么、优先做什么”，是可控性的来源。典型规则包括：权限边界（只能访问指定目录、数据库与接口）、行为规范（删除数据、对外发送等高风险操作前必须请求人工确认）、输出约束（遵循指定格式、注明信息来源、不泄露敏感字段）、流程约束（单次任务最多执行多少步、失败重试几次后必须上报）。没有 Rules 的 Agent 就像没有规章制度的执行者，能力越强，风险越大。Rules 通常通过系统提示词、配置化策略与权限系统共同落地。

5. Hooks：运行过程中的干预点

Hooks 是埋在 Agent 运行链路上的事件钩子，允许在关键节点注入自定义逻辑。常见挂载点包括任务开始前、每次模型调用前后、每次工具调用前后、任务结束或异常时。典型用途：

• 安全治理：工具真正执行前对参数做敏感信息审查与越权检查，不通过则拦截或改写；
• 审计记录：把每次工具调用的输入输出自动写入日志，满足合规要求；
• 质量增强：调用前自动补全上下文，返回后自动校验格式、触发重试；
• 流程编排：特定事件发生时通知人工介入或触发下游流程。

如果说 Rules 是“写在纸上的制度”，Hooks 就是“执行制度的检查岗”——它让约束真正生效在每一次动作上，而不是停留在提示词层面。

6. Harness：承载一切的运行框架

Harness 直译为“马具、背带”，在软件语境中指“运行脚手架”，是 Agent 系统中最容易被忽视、却最能体现“系统”二字的部分。其职责包括：

• 循环控制：驱动“思考—行动—观察”主循环，管理终止条件与最大步数；
• 状态管理：维护会话历史、任务进度与中间产物，必要时做长短期记忆分层；
• 调度执行：接收模型输出的工具调用请求，真正执行并回传结果，处理超时与失败重试；
• 策略实施：加载 Rules、注册 Hooks，把治理逻辑织入执行链路；
• 可观测性：输出结构化日志与执行轨迹，让每一次行为可回放、可审计。

一个直观的判断标准：把 Model 从系统里换掉，如果整个 Agent 依然能运行（只是聪明程度变化），说明 Harness 层是健全的；如果换个模型系统就散架，那构建的就不是系统，而是一次模型调用的包装。

四、工作原理：感知—规划—行动—反馈的闭环

把六层组件装配起来后，Agent 处理一个任务的完整过程大致如下：

1. 目标接收与澄清：Harness 接收用户目标，必要时由 Model 先澄清模糊之处、补齐上下文；
2. 任务规划：Model 将目标拆解为有序的子步骤，形成初步计划；
3. 动作选择与执行：Model 依据当前状态选择工具或技能，Harness 实际执行，Hooks 在执行前后介入校验；
4. 结果观察：执行结果写回上下文，成为下一步推理的输入；
5. 反思与修正：Model 对比目标与现状调整计划——发现搜索结果不相关就换关键词，发现代码报错就调试重写；
6. 循环直至终止：目标达成、触发终止规则或达到步数上限后，汇总输出并归档过程。

其中第 4、5 步是 Agent 与“一次性生成”的本质区别：反馈进入上下文，决策随之调整。Agent 的智能不仅体现在“想得对”，更体现在“错了能自己发现、自己纠正”。支撑闭环的两个工程要点是上下文管理与记忆机制：任务变长时需要压缩、摘要或分层存储，把细节放进外部存储、需要时再检索回来；跨会话场景还需持久化记忆，记住用户偏好与历史结论。

五、典型应用场景

Agent 适合“流程不固定、需要理解非结构化输入、且可拆解为多步操作”的任务：

• 软件研发：按需求描述生成代码、定位并修复缺陷、执行测试与代码审查，作为开发者持续协作的助手；
• 客户服务：多轮对话中自助查询订单、办理退换、排查常见问题，无法解决时再升级人工；
• 数据分析与运营：自然语言发起取数、清洗、生成报表，并把结论定期推送给相关人员；
• 办公自动化：会议纪要整理、文档起草、邮件分诊、日程协调等事务性工作；
• 运维排障：接收告警后自动收集日志与指标、定位根因、执行预案并记录处理过程。

从落地路径看，企业可以自建 Harness，也可以依托云上通用能力组装——例如使用云服务商的大模型推理服务充当 Model 层，配合函数计算、对象存储、日志监控等通用产品搭建执行与治理设施；以百度智能云为例，其提供的大模型与智能体相关通用能力，可作为企业构建此类系统的选项之一。

六、相关概念辨析

• Agent 与大模型：模型是被动的推理函数，Agent 是包含模型在内的完整系统；模型是必要组件，但只有模型不构成 Agent。
• Agent 与对话机器人：传统对话机器人按预设话术树或意图路由应答，本质是“检索与匹配”；Agent 围绕目标自主规划动作并真正执行。前者答“怎么办”，后者替你“办”。
• Agent 与工作流：工作流是人工预先编排的确定性路径，每个分支都要写死；Agent 的路径由模型运行时动态决定。实践中两者常结合：确定性环节用工作流保证稳定，开放性环节交给 Agent 灵活应对。
• Agent 与 RPA：RPA 依赖界面元素定位与脚本回放，环境一变就失效；Agent 依赖语义理解驱动工具调用，对界面与接口变化有更强适应力，可视为更鲁棒的“认知型自动化”。
• Agent 与工具调用：工具调用只是模型的一种输出形式；配上循环、状态、治理与执行框架之后，才升级为 Agent。

七、使用注意事项

• 安全与权限：遵循最小权限原则，为 Agent 单独配置受限凭据；对删除、外发、资金类操作设置人工确认门槛；通过 Hooks 审计每一次工具调用的输入输出。
• 可控性设计：务必设置最大循环步数、超时与失败升级机制，防止任务陷入死循环或无意义重试；关键业务链路建议保留“人工接管”入口。
• 成本控制：Agent 是多轮调用，token 消耗与调用次数会随任务长度增长。需监控单任务平均成本，必要时通过压缩上下文、缓存中间结果、大小模型分工来优化。
• 评估与测试：Agent 行为具有非确定性，单次输出比对不足以评估质量，应围绕“任务完成率、平均步数、工具调用准确率、越界次数”等指标建立评测集并持续回归。
• 可观测性：完整记录每一步的思考、动作与结果，形成可回放的执行轨迹，这既是排障依据，也是合规审计的基础。
• 循序渐进：从确定性较高、容错空间大的场景切入（如内部知识问答、文档处理），积累工程经验后再扩展到高风险核心流程。

八、总结

回到最初那句话：AI Agent 不是模型，而是以模型为核心的系统。六层组件各司其职——Model 贡献智能，Tool 连接世界，Skill 沉淀方法论，Rules 划定边界，Hooks 落实治理，Harness 承载全局。判断一个产品或方案是不是真正的 Agent，不必看概念包装，只需看一个标准：它能否在反馈中持续修正，直至完成任务。理解了这套“系统观”，无论是选型、评估还是自建智能体，都能抓住真正的关键。