企业官网建设流程全解析

当我们第一次接触 AI Agent 时，最容易形成的理解是：

Agent = 大模型 + 工具调用

这个说法没有错，但只适合入门。

它能够解释为什么大模型可以查询数据、发送邮件或者执行代码，却无法解释更多现实问题：

• 为什么同一个模型，在不同 Agent 产品中的表现差异很大？

• 为什么有些 Agent 能够连续工作几十分钟，有些执行几步就偏离目标？

• 为什么模型已经很强，Agent 仍然会重复调用工具、忘记任务要求或者错误判断任务已经完成？

原因在于，真正可用的 Agent 从来不只是一个模型，也不只是给模型增加几个接口。

它更接近一套围绕目标持续运行的系统：

模型负责理解和判断，Harness（基础架构）负责提供上下文、能力、环境、反馈与边界。

一、先从一个最小 Agent 开始

一个最基本的 Agent，可以抽象为下面的执行循环：

与普通大模型应用相比，最大的区别并不是“是否调用了工具”，而是系统能否根据执行结果不断调整下一步行动。

• 普通大模型应用：输入一次 → 生成一次

• Agent：目标驱动 → 多步行动 → 持续反馈 → 结果交付

因此，一个 Agent 至少要解决三个问题：

1. 现在要完成什么？

2. 下一步应该做什么？

3. 如何判断已经完成？

围绕这三个问题，才能理解 Agent 的各个组成部分。

二、不要再把 Agent 看成一串组件

传统资料通常会列出：Model、Instructions、Context、Tools、Memory、Planning、Execution、Observation、Feedback、Guardrails 和 Evaluation。

这些概念都很重要，但如果只是逐个解释，读者很容易记住名词，却仍然不知道它们如何共同工作。

更容易理解的方式，是将 Agent 划分为五个层次：

这五层共同构成一个完整的 Agent。

三、第一层：目标与指令

Goal | 目标

很多 Agent 失败，并不是因为模型能力不足，而是因为任务目标本身不清晰。

例如“帮我分析这个项目”，可能意味着：分析项目架构、分析代码质量、分析进度风险、查找功能缺陷，或是生成一份管理报告。目标不同，Agent 选择的上下文、工具和完成标准也完全不同。

因此，生产级 Agent 需要的不只是一段 Prompt，而是一份相对清晰的“任务契约”。

一份完整的任务目标，需要说清楚期望结果是什么、作用范围覆盖哪里、约束条件有哪些、完成标准如何验证，以及终止条件何时触发。

目标越清晰，Agent 越容易选择正确的行动。

Instructions | 指令

Instructions 用来规定 Agent 应该如何工作，通常涵盖以下方面：

角色定位工作原则执行流程输出格式工具使用规则项目约束安全要求人工确认操作

过去人们常把 Instructions 理解为“系统提示词”。但随着 Agent 工程化发展，指令已经不再只是一段放在对话开头的文字，它还可能存在于项目规则文件、Agent Skills、工作流节点、工具权限配置等更多地方。

因此，Instructions 更接近一套可以被系统加载和执行的运行规则，而不只是 Prompt Engineering。

四、第二层：模型与决策

Model | 模型

模型是 Agent 的认知核心，负责理解用户目标、分析当前信息、识别任务意图、生成计划、选择工具、判断工具结果并生成最终输出。

但是，模型并不直接等于 Agent。同一个模型放入不同的上下文、工具和执行环境中，可能产生完全不同的效果。

模型提供通用智能，Agent 系统负责把这种智能约束到具体任务中。

模型的选择也不一定是固定的。一个生产级 Agent 可能同时使用大模型处理复杂规划、小模型完成分类路由、专用模型处理特定模态、本地模型处理敏感数据，甚至让不同模型相互审查结果。

因此，Model 在现代 Agent 中逐渐从“唯一的大脑”，变成可以被运行时动态调度的认知资源。

Planning | 规划

规划是将目标转换为可执行行动的过程。现代 Agent 的规划方式灵活可变：

当前更实用的做法是：计划一部分、执行一部分、根据反馈继续修正。

五、第三层：上下文与记忆

Context | 上下文

上下文是模型在当前这一步能够看到的全部有效信息，可能包括用户目标、系统指令、任务状态、对话历史、相关文档、工具返回值等。

过去，人们主要关注 Prompt 应该怎么写。现在更重要的问题已经变成：

在当前步骤中，模型究竟应该看到什么？

上下文不是越多越好。当所有信息不断塞进模型时，会出现 Token 成本增加、重要信息被淹没、过期信息干扰判断、长任务逐渐偏离目标等问题。

因此，成熟的 Agent 需要对上下文进行选择（只加载相关）、压缩（长历史转为摘要）、隔离（子任务独立）、更新（移除过期信息）和持久化（关键结果存出窗口外）。

Memory | 记忆

Context 和 Memory 经常被混为一谈。可以用一个简单方式区分：

Context 是 Agent 当前看到的信息，Memory 是系统保存并可能在未来重新取出的信息。

记忆可按层级划分：

工作记忆会话记忆长期记忆经验记忆程序性记忆

记忆也不是保存得越多越好。一个可用的记忆系统还需要处理信息是否值得保存、何时过期、冲突如何处理、敏感信息是否允许存储等问题。

没有治理的长期记忆，可能从能力增强机制变成长期风险来源。

六、第四层：工具、技能与执行环境

Tools | 工具

工具让 Agent 从“能够理解”走向“能够行动”。常见工具包括数据工具（数据库／知识库／搜索）、办公工具（邮件／日程／文档）、开发工具（代码仓库／终端／测试）、业务工具（订单／审批／项目管理系统）以及计算机操作工具（浏览器／文件系统）等。

模型一般不会直接执行这些操作，而是生成结构化调用请求，再由程序完成校验和执行：

模型选择工具 → 生成调用参数 → 系统校验权限和数据 → 执行实际操作 → 返回执行结果 → 模型决定下一步

工具设计的质量会直接影响 Agent 的稳定性。一个好的工具应当：

名称清晰功能单一参数明确返回值结构化错误信息可理解操作幂等权限边界明确

很多所谓的“模型调用错误”，实际是工具描述模糊、返回值混乱或者权限设计不合理。

Skills | 技能

Skills 是近期 Agent 架构中越来越重要的一层：

• Tool 主要告诉 Agent：可以做什么。

• Skill 则告诉 Agent：一类任务应该怎样完成。

例如，“生成技术选型报告”这个 Skill，可能包含分析步骤、信息来源要求、对比维度、输出模板、事实校验规则以及可调用的工具等。Skills 在需要时按需加载，而不是将所有领域知识永久放入系统 Prompt。

因此：Tools 提供操作能力，Skills 提供任务方法。

Execution | 执行

Execution 是将模型的行动决策变成真实结果的过程，可能发生在后端服务、浏览器、用户桌面、容器、云端 Sandbox 或企业业务系统中。

生产级执行层需要统筹：超时与重试、幂等与并发、取消与资源限制、网络隔离与文件权限、凭证管理与失败恢复。

这也是 Agent 与普通聊天应用最明显的区别：聊天应用回答错误主要影响内容质量，而Agent 执行错误则可能修改文件、发送消息、消耗资源或者改变业务数据。

行动能力越强，执行环境越需要被严格控制。

Environment | 环境

环境在 Coding Agent 和 Computer Use 场景中已成为核心组成部分。Agent 需要知道当前有哪些文件、浏览器显示了什么、命令执行后发生了什么、代码是否编译成功、业务系统返回了什么状态。

环境不仅提供工具，也产生新的状态。

因此，Agent 实际运行的是一个闭环：

感知环境 → 采取行动 → 环境变化 → 再次感知

这与早期“模型调用一个 API，然后生成答案”的模式已明显不同。

七、第五层：观察、反馈与评估

Observation | 观察

Observation 是 Agent 对行动结果的读取和理解：搜索返回了什么、API 是否成功、测试是否通过、文件是否生成、数据是否变化。

观察结果必须重新进入 Agent 的上下文，才能帮助模型决定下一步。

工具返回值不是最终结果，而是 Agent 下一次决策的输入。

高质量的 Observation 应尽量结构化，明确表达操作是否成功、实际发生了什么、返回了哪些数据、是否存在异常、下一步可以做什么。如果工具只返回一大段混乱日志，模型就很难做出稳定判断。

Feedback | 反馈

Observation 只是“看到了什么”，Feedback 则进一步告诉 Agent“做得怎么样”。

反馈可以来自确定性反馈（编译结果／单元测试／Schema 校验）、模型反馈（结果审查／错误分析）、用户反馈（批准／拒绝／修改意见）以及环境反馈（页面变化／外部系统响应）。

一个成熟的 Agent 不应只依赖模型自我反思，而应优先使用可重复、可验证的外部反馈。

Evaluation | 评估

Feedback 主要服务于当前运行，Evaluation 则用于判断 Agent 在一组任务上的整体表现。

评估 Agent 表现，可以从任务层面（完成率／正确率）、行为层面（工具选择与参数准确率／步骤数）、资源层面（Token 消耗／响应时间／重试次数）和安全层面（人工介入率／违规率／业务价值）综合衡量。

Agent 的评估对象，不应只是一次输出，而应是完整的执行轨迹。

八、Guardrails：护栏不是最后一层过滤器

很多系统将 Guardrails 理解为输入输出内容审核。但对 Agent 来说，这远远不够——因为 Agent 不只是说话，还会行动。

护栏应贯穿全程：

输入阶段规划阶段工具阶段执行阶段输出阶段记忆阶段

对于高风险操作，更合理的流程是：

模型提出操作 → 系统检查权限和风险 → 必要时请求人工确认 → 在受控环境中执行 → 记录完整操作证据

九、把组件重新放回运行循环

现在可以把前面的内容重新组合成一个完整的 Agent Loop：

1. 接收目标：Goal + Instructions —— 明确做什么、怎么做、不能做什么。

2. 构建当前认知：Context + Memory —— 选择本次决策需要看到的信息。

3. 形成行动决策：Model + Planning —— 分析状态并决定下一步。

4. 执行实际操作：Tools + Skills + Execution —— 调用能力，在真实环境中完成行动。

5. 获取环境变化：Observation —— 读取工具、系统和环境返回的结果。

6. 检查执行质量：Feedback + Guardrails —— 判断是否正确、安全，是否需修正或人工确认。

7. 判断任务是否完成：Evaluation —— 根据完成标准判断继续、结束或失败。

未完成：更新上下文，进入下一轮
已完成：输出结果和执行证据

这才是一个完整的 Agent Loop。

十、一个现实例子：Coding Agent 修改项目代码

以“为一个 Spring Boot 项目增加接口限流”为例：

• 目标与指令：明确只修改 API 接入层，保持兼容，补充自动化测试。

• 上下文与记忆：读取项目结构、技术栈、现有安全配置和编码规范。

• 模型与规划：判断在哪一层增加限流，生成修改步骤。

• 工具与执行：搜索代码、修改文件、运行 Maven 构建和测试。

• 观察：读取编译错误、测试结果和代码差异。

• 反馈：根据测试失败原因继续修复。

• 护栏：禁止修改生产配置和密钥文件，限制命令和网络访问。

• 评估：检查项目是否构建成功、新增测试是否通过、原有接口是否兼容、修改范围是否符合要求、是否输出验证证据。

这时可以看到，真正决定 Coding Agent 是否可靠的，并不只是模型会不会写代码，更关键的是它读取了什么上下文、可以使用哪些工具、能在什么环境中执行、失败后获得什么反馈、用什么标准证明任务已完成。

十一、从单 Agent 到协作系统

前面的结构主要描述单个 Agent。当系统进一步扩展，Tools 之外还可能出现其他 Agent：

主控 Agent（理解目标、分配任务）→ 搜索 Agent（收集核实资料）→ 分析 Agent（整理数据、生成结论）→ 审查 Agent（检查事实和完整性）

随着 A2A 等协议发展，不同语言、框架和厂商构建的 Agent，可以通过统一协议完成能力发现、任务委托和状态交换。

但无论系统中有一个还是多个 Agent，每个 Agent 仍需解决相同的问题：目标是什么、当前知道什么、可以做什么、已经发生了什么、结果是否可信、行动是否安全。

十二、一个更加完整的 Agent 心智模型

到这里，可以给出一个比“模型＋工具”更加完整的表达：

其中Harness（基础架构）包括：指令、上下文、记忆、工具、技能、规划、状态、执行、反馈、评估、护栏。

十三、写在最后

一个智能体到底由什么组成？

表面上看，它由模型、指令、上下文、工具、记忆、规划、执行、观察、反馈、护栏和评估组成。

但从本质上看，它只有一条主线：

围绕一个目标，在受控环境中持续感知、决策、行动和验证。

• 模型让 Agent 能够理解和判断。

• 上下文和记忆让它知道当前发生了什么。

• 工具、Skills 和执行环境让它能够真正采取行动。

• Observation 和 Feedback让它知道行动带来了什么结果。

• Guardrails限制它可以做什么。

• Evaluation负责回答最关键的问题：这个任务真的完成了吗？

因此，接触任何 Agent 框架之前，首先应该建立的不是某个框架的 API 使用方法，而是这套与技术实现无关的心智模型：

目标 → 上下文 → 决策 → 行动 → 观察 → 反馈与验证 → 继续执行或交付结果

框架会不断变化，模型会持续升级，协议和工具也会快速演进。但一个可靠 Agent 的核心始终不会改变：

它不仅要能够采取行动，还必须知道为什么行动、行动后发生了什么，以及如何证明目标已经完成。

上一篇回顾：

【第一部分：认识 Agentic AI】2. AI Agent、Agentic AI 和普通大模型应用，到底有什么区别？-CSDN博客

下一篇将进一步介绍：

智能体的工作循环——从 ReAct 到 Plan-Execute