1、AI Agent 的工作原理？
AI Agent 的工作原理可以从感知、认知 & 推理 & 决策、行动、反馈和学习，4 个关键过程来解释。
感知阶段
这是唤醒 AI Agent 的第一步，感知内容分为。
- 来自物理世界的信息：包括来自客户端的任务，自然语言、代码、多模态等，以及通过传感器、摄像头、麦克风硬件设备的传感信息。
- 来自虚拟环境的信息：从数据库、外部 API 接口等收集到的信息。
认知 & 推理 & 决策阶段
一旦 AI Agent 感知到环境信息，依赖深度学习、强化学习带来的训练结果，对这些信息进行识别与分析，以便作出明智的决策。这个过程中，会借助 RAG、联网搜索、外部应用和系统调用。
这一阶段是 AI Agent 行为的核心，直接决定了后续行动的有效性。但由于深度学习、强化学习的模型，依旧缺乏完全的可解释性，是输出结果不确定性的主要原因之一。
对于复杂任务，决策并不是一个结果，而是需要经历和环境感知、认知和推理之间反复交互的过程。因此还会受到提示词工程的影响，例如我们在《Promt Engineering》分享的输出长度、top-K 和 top-P、Temprature 等参数，都会影响到最终的决策结果。
行动阶段
最终，AI Agent 根据其决策采取行动。这一阶段的目标是执行之前所做的决策，并进行输出，例如一个模型、一份计划书、甚至是一个物理界的执行动作（如自动驾驶中的车辆控制、机器人执行任务、下单等）。
反馈与学习
AI Agent 的能力不仅仅停留在执行阶段，它还会不断地根据执行结果进行反馈，并在每次任务后学习，例如 Monica 提供了记忆功能，通过学习，AI Agent 能够逐渐优化自身的决策过程和行动策略。这一过程通常使用强化学习或其他在线学习技术来实现。
2、如何提升 AI Agent 的输出效果？
从 LangChain 的调研来看，41% 的受访者认为性能质量是构建可靠智能体系统的最大限制。性能质量表现不佳常因模型不够好或传递了错误（或不完整）的上下文，后者更加常见，包括不完整或简短的系统消息、模糊的用户输入、无法访问正确的工具、工具描述不佳、未传递正确的上下文、工具响应格式不佳等。
因此提升 AI Agent 的输出效果，关键也在于模型质量和环境反馈（Context），我们将环境反馈拆解成工具和指令来展开描述。
模型类型和质量
不同模型在任务复杂性、性能和成本方面具有不同的优势和权衡。即便是同一个厂商，也会区分推理类模型、复杂任务类模型、多模态模型。我们应根据任务类型选择更适合的模型。下图是 Qwen 官网对主流模型的比对表。
不同厂商相同类型的模型，输出效果也不一样，并且是动态变化的。就好像你的学生，每次拿第一的不会永远是同一个人，不同科目的，也会有不同的排名。
人类竞技有单场胜负，更有 N 连冠。但是人工智能遍布生活中的每一个场景，不是单次结果论英雄的竞技场。因此在供应链视角，企业通常会采用多模型策略，通过 AI 网关在后端对接多个模型，一是为了提供更加丰富且对口的输出结果，供用户使用；二是满足鉴权、安全防护、限流、可观测、审计等方面的企业级需求。
工具
工具是指 AI Agent 使用外部应用程序或系统的 API 来扩展代理边界的功能。例如 LLM Chatbot 在处理复杂的科学和数学问题时，"幻觉" 会被放大。此时，AI Agent 集成 Wolfram Alpha 的 Server，能够准确地执行计算任务，避免因模型自身的局限性而导致的错误。与大语言模型相比，Wolfram Alpha 基于广泛的数学和科学知识库，在处理复杂的数学公式、物理定律和科学概念时，能够进行精确的计算、符号操作和公式推导。
目前主流的技术实现方式是 MCP 和 Function Call，Function Call 是最早提出的，MCP 是在此基础之上做了协议的标准化。另外，OpenAI 今年 1 月推出 Operator 的形式 （截屏，以视觉方式读取浏览器的页面信息）来和外部页面进行交互，通过视觉算法模拟用户操作来访问网页信息。优势是 token 消耗少，即便没有 API 接口，也可以进行交互，且更容易适应不同的网站设计和布局变化。但由于客户端实现成本高，视觉算法导致的出错率不可控，服务端没有参与感等原因，并未像 MCP 那样形成广泛共识。 这算是两个技术流派，MCP 和 Function Call 是工程派，Operator 是算法派。
对大部分用户而言，并不会太关注工具背后的技术实现方式，更关注的是工具的添加，别给原本就容易产生幻觉的大模型新增烦恼。其次是信任感，例如 DeepSeek 首次将深度思考的过程呈现给用户时，这对 Chatbot 的体验而言，获得了大幅提升，随后各家都相继推出深度思考的功能。AI Agent 也是类似。MCP 和 Function Call 在用户端呈现的是，Agent 调用 MCP tool 的过程，是代码语言，而 Operator 呈现的是用户语言，例如在 Manus 里，会展示他在页面浏览器的操作过程。后者因为更透明，给用户带来更多的信任感。
另外，从供应端来看，工具虽然拓展了 AI Agent 的想象空间，但也带了一些难题：
- 信息对齐难：LLM 读取 MCP Server 的信息时，就像让两个哲学家用摩斯密码聊黑格尔，调试得当神配合，搞错了那就是哲学灾难。因此，构建 MCP Server，少不了和大模型联调的过程。
- 协议开销大：相比 Chatbot，AI Agent 的上下文记忆链条、任务步骤更多，实时任务秒变 "慢动作回放"，单个任务可能耗时半小时。
这也催生了 MCP as a Service，例如 MCP Marketplace，帮你找到干净好用、无须调优的 Server，通过网关的权限和标签能力来控制工具的使用范围；当工具数量的增加，使用 MCP Registry 来解决工具在批量生效、调试、历史版本管理灰度、健康检查的需求。以及 AutoMCP，让模型通过反复试验来学习工具的使用方法，而不只是通过提示工程来优化工具的调用效果。
指令
指令分为两类，一类是终端用户提问时的提示词技巧，一类是开发者侧训练大模型用的提示词工程。但无论是哪一种，以下 4 个可以看作是改善输出结果的原则。
-
利用现有文档：将现有的操作流程或政策文件转换为智能代理可以理解的指令。
- 终端用户：上传报告、图片，让大模型提取其中内容进行二次加工。
- 开发者：只要是涉及医疗领域的任务，一律自动追加 "答案仅供参考，请咨询专业医生"。
-
分解任务：将复杂的任务分解为更小、更清晰的步骤，减少歧义。
- 终端用户：根据提示词，让大模型输出一篇报告，改为按章节、段落来输出。
- 开发者：将分解用户的任务进分解成计算机语言可以描述和执行的步骤，并针对多选答案和用户完成核实后再执行下一步。
-
定义明确的行动：确保每个步骤都有具体的行动或输出，避免模糊不清的指令。
- 终端用户：将自己的任务尽可能拆解成计算机能理解的描述，而非即便自然语言也会出现理解偏差的任务或指令。
- 开发者：通过自然语言理解（NLU）将指令拆解成可以精确计算的步骤。
考虑边缘情况：提前规划如何处理用户提供的不完整信息或意外问题。出现问题时能自主纠错，在遇到故障时还可暂停执行并将控制权交回用户。
作为用户，如果编写指令有困难，可以将你觉得满意的任务结果，例如一篇论文、一张图片，喂给模型，由他来生成指令，这是设计指令的有效技巧。同时，指令要常用，内化成习惯，才能更高效的使用 Agent，这就像大部分企业管理者每天早上到公司都会先打开数据系统了解过去 1 天的业务数据，这时候，"打开数据系统" 就是一则对人脑的指令。
指令也正在内化为大模型的能力，通过对话引导的方式来帮助用户将自己的任务描述的更加清楚，因为很多情况下，我们对大模型的输出效果不满意，不是其不够智能，而是我们没有将任务描述、分解的足够明确。来看一个例子。
当我提问：AI 网关在 Agent 构建过程中，起到了哪些作用？显然这个任务描述的不够明确。于是，大模型给出了描述更加明确的方式，如下。
