AI Agent 核心概念与架构

这道题其实是在问，我们怎么让大模型从被动回答问题变成主动解决问题。传统LLM你问一句它答一句，但[[Agent]]不一样，它是一个自主决策的循环：规划、推理、行动、观察，然后根据观察结果再规划，直到任务完成。这个循环里最关键的，一个是推理范式，一个是工具调用。

先说推理范式，最常用的是 [[ReAct]]，就是让模型边想边做。你问它一个复杂问题，它会先想一个计划，然后调用工具去查，看结果，再想下一步。这和[[Chain-of-Thought]]不一样，CoT是纯思考，适用于数学题那种封闭问题；而ReAct更适合开放场景，因为它的思考会指导行动，行动的结果又会修正思考。实际落地时，我通常会把两者结合，简单推理用CoT，涉及工具交互的用ReAct。

再一个就是工具调用，也就是 [[Function Calling]]。模型生成一个结构化的调用指令，比如search_order(order_id)，系统执行这个函数，把结果返回给模型，模型再综合回答。这个机制依赖模型本身的能力，如果模型不支持原生Function Calling，就得靠Prompt工程来模拟，但稳定性会差不少。这里有个坑：工具调用的参数很容易出错，比如订单号传错格式，或者工具返回的结果太长把上下文撑爆了。所以上线前我会特别关注参数校验和结果截断。

说到架构，现在主流是单Agent和多Agent两种。单Agent适合简单任务，比如查个天气。复杂任务我会倾向多Agent分工，一个负责规划，一个负责执行，一个负责验证。比如Devin那种，它内部有多个Agent合作完成软件开发。但多Agent的挑战是协调和成本，每个Agent都要消耗token，而且Agent之间沟通可能有信息丢失。所以我的取舍是：任务够复杂才用多Agent，否则单Agent加ReAct循环就够了。

典型场景我重点讲智能客服。传统客服是人工查订单，或者用关键词匹配。用Agent之后，用户说“我退款没到账”，Agent可以自动调用订单查询工具，查退款状态，如果显示已处理，再调用支付工具查流水，最后定位到银行延迟，然后给用户解释。这个过程中Agent的价值在于端到端自主处理，不用人工介入。但前提是工具接口稳定，而且Agent有清晰的权限边界，不能让它调用删除订单这种危险操作。常见失败场景是Agent在工具调用循环里出不来，比如查一次失败就反复查，白白浪费token。我会给循环加一个最大步数限制，超时就让步给人工。

还有一个方向，就是Agent的记忆管理，尤其长期记忆。现在很多方案用[[向量数据库]]存历史经验，但怎么在记忆里检索到最相关的信息，同时避免记忆污染，这是个值得深入的问题。

所以整体来说，我会把Agent看作大模型从知识问答走向任务执行的关键一步。它不是万能的，稳定性、成本和安全性都是落地必须解决的问题。我的选择是，先在小场景里跑通ReAct加单Agent，验证价值，再逐步扩展。