1. 从一次模型调用说起我们到底在“调用”什么当我们在代码里写下model.generate(prompt)或者通过 API 发送一个请求时我们通常认为自己在“调用模型”。这个认知没错但过于简化了。在 AI Agent 的语境下这次调用远不止是输入文本、输出文本那么简单。它更像是一次对“世界模型”的咨询我们提交的是一个“意图”而模型返回的是一个“行动计划草案”。让我用一个更具体的例子来解释。假设我们想让 Agent 帮忙订一张从北京到上海明天下午的高铁票。一个初级的想法可能是直接把这句话作为提示词Prompt扔给大语言模型LLM。模型可能会回复“好的我可以帮你订票。请提供你的身份证号和12306账号密码。” 这显然不是我们想要的。我们期望的是一次完整的、可执行的行动。所以更合理的“一次模型调用”的输入应该是一个结构化的“思考上下文”它至少包含目标用户的核心意图订票。状态当前已知信息出发地北京目的地上海时间明天下午。约束行动必须遵守的规则不能索要用户密码必须通过合法接口。可用工具Agent 当前可以调用的函数列表及其描述例如search_train_tickets(date, from, to)book_ticket(ticket_id, passenger_info)。模型在这次调用中的任务不是直接生成最终答案而是根据这个丰富的上下文生成一个或多个“下一步该做什么”的建议。这个建议在技术实现上通常是一个结构化的 JSON 对象比如{ “thought”: “用户想订明天下午北京到上海的高铁票。我需要先查询符合条件的车次。我有 search_train_tickets 这个工具可用。”, “action”: “调用工具”, “action_input”: { “tool_name”: “search_train_tickets”, “arguments”: { “date”: “2023-10-27”, “from”: “北京”, “to”: “上海” } } }或者如果信息不足它可能会决定“行动”是“向用户提问”并给出需要提问的内容。所以理解“一次模型调用”是理解 Agent 工作的基石。这次调用的输入输出从简单的“问答”升级为了“基于认知上下文的决策”。模型扮演的不再是“百科全书”或“诗人”而是一个在给定环境和目标下的“策略思考者”。这个思考过程被强制用结构化的语言如 JSON表达出来以便后续的程序能够精确地解析和执行。注意这里存在一个关键的设计选择——是否强制模型输出结构化内容JSON。早期实验或简单场景中模型可能输出自然语言再由一个额外的“解析器”去提取意图和参数。但这引入了额外的复杂性和出错可能。目前主流的 Agent 框架如 LangChain、LlamaIndex 的早期版本以及后来的专业框架如 AutoGen、CrewAI都倾向于在提示词工程中明确要求 JSON 格式或使用函数调用Function Calling这种更原生、更可靠的结构化输出方式。OpenAI 的 GPT 系列、Anthropic 的 Claude 都支持将工具函数描述作为输入的一部分模型可以直接返回“调用哪个函数、参数是什么”的标准化响应。2. 单次决策的局限性为什么需要“循环”如果一次模型调用就能解决所有问题那 Agent 的概念就不会如此复杂了。现实世界的任务往往是多步骤的、依赖中间结果的、并且可能遇到意外情况的。继续用订票的例子第一次调用模型决定查询车次并输出调用search_train_tickets工具的指令。执行工具程序解析指令真正调用这个函数可能是一个封装好的 API。函数返回结果[ {“车次”: “G1”, “时间”: “14:00”, “余票”: “有”}, {“车次”: “G3”, “时间”: “15:30”, “余票”: “无”} ]。新问题出现现在该做什么直接订 G1 吗用户可能对时间有偏好或者需要选择座位。这时程序无法自行决定。这就是单次调用的局限性模型只规划了“第一步”它不知道第一步执行后的结果自然也无法规划第二步。因此我们必须把第一步的结果连同最初的目标和上下文再次喂给模型让它做第二次决策。这个过程就是“循环”的核心驱动力。第二次调用的输入上下文变得更丰富了原始目标订票。历史记录之前已经执行了“查询车次”并得到了结果列表。当前状态现在知道有 G1 可选G3 无票。可用工具依然是search_train_tickets和book_ticket。这次模型可能会生成新的决策{ “thought”: “已查询到明天下午有 G1 次列车有余票。现在需要向用户展示结果并确认或者根据默认策略直接预订。由于没有用户的进一步指示我应该先询问用户是否预订 G1 次。”, “action”: “向用户提问”, “action_input”: “已为您查询到明天下午14:00的G1次列车有余票。请问是否为您预订此车次” }或者在一个更自动化的场景中Agent 的设定可能是“找到最早的一班有余票的车并直接预订”那么它的决策可能就是直接调用book_ticket。无论哪种情况你都能看到这个模式观察获取当前状态和记忆 - 思考模型基于上下文决策 - 行动执行模型决定的动作 - 再观察获取行动结果。这个循环就是著名的ReAct (Reason Act)框架的核心思想也是绝大多数现代 Agent 系统的运行时Runtime基础。这个循环会一直持续直到模型决策出一个“最终行动”比如“任务完成将订票成功信息返回给用户”或者“任务失败告知用户原因”。这个“最终行动”通常对应一个特殊的动作类型如final_answer。3. 构建可运行的执行循环Runtime 的核心组件一个健壮的 Agent 执行循环Runtime不能只是一个简单的while循环。它需要一系列组件来管理状态、处理决策、执行动作并应对异常。我们可以将其拆解为以下几个核心模块3.1 状态管理State Management这是 Runtime 的“记忆体”。它需要维护一个随着循环不断演进的“状态对象”。这个状态通常包括任务目标初始的用户请求或系统指令。对话历史/执行轨迹记录每一步中模型的“思考”thought、执行的“行动”action、行动的“输入”input以及行动的“输出”observation。这是最重要的部分它让模型在每一步都能拥有完整的“上下文”。中间结果例如上例中查询到的车次列表。循环控制变量比如当前步数用于防止无限循环。状态的设计直接影响模型的性能。如果历史记录太长可能会触及模型的上下文长度限制并且包含大量无关信息。因此高级的 Runtime 会引入“状态压缩”或“记忆摘要”机制例如只保留最近 N 步的详细记录或将更早的步骤总结成一段简短的摘要。3.2 决策引擎Decision Engine这是 Runtime 的“大脑”主要负责组织每次模型调用的上下文Prompt。它的工作流程是从状态管理器获取当前完整状态。根据状态和预设的提示词模板组装出本次发送给模型的提示词。这个模板会清晰地定义模型的角色、可用的工具、输出格式要求并将历史轨迹和当前目标以结构化的方式嵌入。调用模型接口发送请求并获取响应。将模型的响应一个结构化的行动指令传递给动作路由器。决策引擎的难点在于提示词工程。如何清晰地告知模型它的角色、可用的行动空间以及历史是决定 Agent 表现好坏的关键。许多框架提供了高阶的抽象如“代理角色”Agent Role定义来简化这部分工作。3.3 动作路由器与执行器Action Router Executor这是 Runtime 的“四肢”。模型决策出的“行动”需要被转化为实际的操作。动作路由器解析模型输出的结构化指令如{“action”: “call_tool”, “tool_name”: “search”...}判断其类型调用工具、提问用户、返回最终答案等。执行器如果动作是“调用工具”则根据tool_name找到对应的函数这些函数需要提前注册到 Runtime 中并传入解析好的参数然后执行它。这个函数可以是任何代码调用一个外部 API、查询数据库、运行一个本地计算甚至调用另一个 Agent。如果动作是“提问用户”在交互式场景下Runtime 会暂停循环将问题输出给用户例如通过聊天界面并等待用户输入然后将用户的回复作为本次行动的“观察结果”observation。如果动作是“最终答案”则循环终止将结果返回。工具Tools的定义至关重要。每个工具都需要有一个清晰的名称、描述和参数模式。模型的函数调用能力严重依赖这些描述来理解工具的功能。好的描述应该是“search_train_tickets(date: str, from_city: str, to_city: str) - List[Dict]根据日期、出发城市和到达城市查询高铁车次及余票信息。” 而不是简单的“查询车票”。3.4 循环控制器Loop Controller这是 Runtime 的“调度中心”负责驱动整个循环流程。它通常实现为一个主循环逻辑伪代码如下state initialize_state(user_task) while not is_task_finished(state): # 1. 决策 action_decision decision_engine.generate_action(state) # 2. 执行 observation action_executor.execute(action_decision) # 3. 更新状态 state.update(action_decision, observation) # 4. 安全检查防止无限循环、错误累积等 if safety_check_failed(state): break return state.get_final_result()循环控制器还需要处理异常比如模型输出了无法解析的指令、工具执行出错、或者循环次数超过最大限制等。一个健壮的控制器需要有错误处理和回退策略例如当工具调用失败时可以将错误信息作为“观察”反馈给模型让模型决定是重试、换种方式还是放弃。4. 从理论到实践主流框架中的 Runtime 实现差异理解了核心组件我们来看看在不同框架中这些概念是如何具体实现的。这能帮助我们更好地选择工具和理解背后的权衡。LangChain Agent ExecutorLangChain 的AgentExecutor是早期最著名的 Runtime 实现之一。它将状态管理、决策、执行封装在一个类里。用户需要定义一个Agent包含 LLM 和提示词模板和一系列Tools。AgentExecutor的run方法内部就封装了上述循环。它的特点是灵活但早期版本在状态管理和复杂流程控制上需要用户做较多工作。它的循环相对“朴素”主要依靠模型在提示词指导下决定下一步。AutoGen微软的 AutoGen 提出了“对话代理”的概念。其 Runtime 更侧重于多个 Agent 之间的协作循环。每个 Agent如AssistantAgent,UserProxyAgent都有自己的系统提示词和能力。它们通过互相发送消息来驱动工作流。UserProxyAgent可以代表用户执行代码或工具调用。AutoGen 的 Runtime 本质是一个多轮对话调度器其循环是由“当某个 Agent 收到消息时根据其角色生成回复”这一规则驱动的。它更擅长构建多角色协作的复杂场景。CrewAICrewAI 在概念上更上一层引入了Crew团队、Agent成员、Task任务三层结构。它的 Runtime 是一个任务执行引擎。它会为每个Task分配一个Agent并按照依赖关系或顺序执行任务。每个Agent在执行其Task时内部会运行一个类似 LangChain 的单 Agent 循环。CrewAI 的 Runtime 核心是任务级的流水线或图执行管理的是宏观工作流而每个节点的微观循环则由底层 Agent 完成。LlamaIndexLlamaIndex 的 Agent 模块如ReActAgent与其强大的数据检索能力深度集成。它的 Runtime 特别擅长在循环中调用其特有的“查询引擎”Query Engine作为工具从私有知识库中获取信息。其循环逻辑与 ReAct 框架一致但工具生态围绕数据检索和生成优化。选择哪个框架取决于你的场景快速构建单一功能 AgentLangChain 的AgentExecutor入门最快。构建多专家协作系统AutoGen 的对话模型非常直观。设计有明确分工的团队流程CrewAI 的抽象更贴合业务规划。核心需求是问答和私有知识库调用LlamaIndex 的深度集成更有优势。5. 开发中的核心挑战与实战心得搭建一个能“跑起来”的循环不难但打造一个“可靠”、“高效”、“好用”的 Agent Runtime会遇到不少挑战。以下是我在实际项目中积累的一些心得挑战一模型的“叛逆”与输出解析模型并不总是乖乖输出你想要的 JSON 格式。它可能在思考部分加入额外的说明或者漏掉引号。一个健壮的 Runtime 必须有强健的解析器Parser。除了用正则表达式做后处理更佳实践是在提示词中强烈要求格式并提供精确的例子。使用支持结构化输出的模型 API如 OpenAI 的response_format或function calling。在解析失败时设计重试机制将错误信息和“请严格按照指定格式重新输出”的指令连同原上下文再次发送给模型。挑战二上下文长度与历史管理复杂的任务可能经历几十个循环步骤每一步的思考、行动、观察都会累积很容易超出模型的上下文窗口。解决方案包括选择性记忆只保留最近几步的完整记录将更早的步骤总结或丢弃。LangChain 的ConversationSummaryBufferMemory就是干这个的。向量化记忆将历史记录存入向量数据库在每一步只检索与当前思考最相关的历史片段。这更复杂但能处理超长历史。任务分解在进入循环前先用一个“规划器”模型将大任务拆解成子任务然后为每个子任务启动一个独立的、历史较短的循环。挑战三工具执行的可靠性与安全性工具是 Agent 影响外界的接口必须谨慎处理。参数验证与类型转换模型输出的参数是字符串调用工具前必须进行类型验证和转换如将字符串“10”转为整数10。缺少这一步会导致运行时错误。异常处理与重试工具调用可能因网络、权限等问题失败。Runtime 应该捕获异常并将其作为“观察”反馈给模型例如“调用搜索 API 失败错误网络超时”让模型决定下一步重试或换方法而不是让整个 Agent 崩溃。沙箱与权限控制对于执行代码如 Python 代码解释器或高风险操作的工具必须在沙箱环境中运行并严格限制其权限文件系统、网络访问等。挑战四循环失控与停滞Agent 可能陷入死循环反复执行相同操作或者在某个步骤“卡住”输出无意义的动作。 mitigation 策略包括设置最大迭代次数最基本的防护。多样性鼓励在提示词中要求模型“尝试与上一步不同的方法”。超时与看门狗为整个循环或单个工具调用设置超时。人工干预点在设计流程时在关键决策点如确认支付、删除数据设置“人工审核”环节让循环暂停等待确认。一个实战技巧给 Agent “洗澡”这是我团队内部的一个比喻。当发现 Agent 在复杂任务中后期表现混乱、开始胡言乱语时往往是因为状态历史记录积累了太多“噪音”。一个有效的技巧是在任务的关键里程碑例如完成一个子目标后主动重置一部分状态。不是全部重置而是保留任务目标和最终结果但清空中间的过程性历史记录然后让 Agent 基于新的、干净的状态开始下一阶段。这就像给 Agent 洗了个澡清除了干扰让它能重新专注。实现上这需要你在设计状态管理时有意识地区分“战略记忆”目标、结果和“战术记忆”具体操作步骤。6. 超越基础循环高级模式与架构展望基础的 ReAct 循环解决了顺序任务但现实世界的问题更复杂。高级的 Agent 系统正在探索更强大的运行时模式1. 规划-执行-反思Plan-Execute-Reflect这不是一个简单的循环而是一个三层架构规划器在任务开始时或当执行受阻时一个专门的“规划”模型可以是同一个 LLM用不同的提示词会生成一个高层次的任务计划列表如1. 搜索信息A2. 分析信息A得到结论B3. 结合B和已知信息C生成报告D。执行器基础的 ReAct 循环但它现在是在执行规划器给出的具体子任务。每完成一个子任务就标记为完成。反思器定期或在失败时检查当前结果与计划的偏差判断计划是否依然可行必要时要求规划器重新规划。这种模式让 Agent 有了更强的全局观和纠错能力。2. 多 Agent 协作与竞争多个具有不同专业能力的 Agent 在一个 Runtime 中被协调工作。例如一个“研究员”Agent 负责搜索和总结资料一个“写手”Agent 负责起草文案一个“批评家”Agent 负责审核和提出修改意见。Runtime 在这里扮演“项目经理”的角色负责在 Agent 之间路由信息、管理对话回合、并最终整合输出。AutoGen 和 CrewAI 主要聚焦于此。3. 分层递归执行Agent 的工具本身可以调用另一个 Agent。这就形成了一个递归的、分层的执行树。顶层的“经理”Agent 将一个复杂任务分解创建几个“员工”Agent 子任务并等待它们返回结果。每个“员工”Agent 自己内部运行着一个独立的循环。这种架构非常适合构建复杂的、模块化的 AI 应用。4. 与外部工作流引擎集成最强大的企业级应用不会让 Agent Runtime 管理一切。而是将 Agent 作为一个智能节点嵌入到现有的工作流引擎如 Airflow、Prefect、Camunda或业务系统中。工作流引擎负责处理严格的业务流程、事务、权限和调度而 Agent 只在需要“智能决策”的环节被调用。例如一个客户投诉处理流程中前面的路由、信息收集由系统完成当需要判断投诉类别和生成初步回复时调用 AgentAgent 给出建议后流程再将建议转给人工坐席审核。这样Agent 的“循环”就被封装在一个更可控、更可观测的业务上下文里。构建 AI Agent 应用从理解一次模型调用开始到设计一个鲁棒的执行循环再到融入更广阔的软件架构是一个层层递进的过程。Runtime 是 Agent 的“发动机”它的设计直接决定了 Agent 的可靠性、效率和智能上限。目前这个领域仍在快速演进没有银弹。最好的学习方式就是选择一个框架我建议从 LangChain 或 AutoGen 开始亲手实现一个简单的 Agent比如一个能联网查询天气并给你穿衣建议的助手去亲身经历从模型调用到循环构建的每一个细节踩一遍该踩的坑。当你看到几行代码真的能驱动一个“智能体”一步步完成任务时你对整个系统的理解会深刻得多。