Kilo 理解：基于ReAct范式的Agent运行机制

本文以AI Agent设计范式为核心，从基础定义、核心组件、主流架构入手，重点拆解Kilo基于ReAct架构的运行流程，概括说明其如何通过"思考-行动-观察"循环解决用户问题，兼顾架构逻辑性与落地可行性。

一、Agent定义

AI Agent是一类以大语言模型（LLM）为核心，具备自主认知、决策、行动与迭代能力的智能体。其核心目标是接收用户高层级目标或模糊需求后，无需人工逐步干预，通过整合记忆、规划任务、调用工具、执行反馈的闭环，自主完成问题解决，本质是"模拟人类思考与行动逻辑"的智能化任务处理载体。

二、Agent核心组件

1. 大脑 - LLM

作为Agent的核心决策中枢，承担所有关键认知任务，核心能力覆盖三点：一是指令遵循，精准解析用户复杂需求、约束条件（如时间、精度要求），明确任务核心目标；二是推理与规划，基于需求进行逻辑拆解，制定分步执行策略，同时在执行中评估中间结果、修正偏差；三是知识整合，融合预训练知识与任务过程中的新信息（如工具返回结果、用户补充反馈），形成综合判断。

2. 记忆模块

用于存储与检索全链路信息，突破LLM无状态与上下文长度限制，分为两级存储：

• 短期记忆：存储当前任务会话内的上下文信息，包括用户初始需求、规划步骤、已执行结果、实时工具反馈等，支撑单轮任务的即时决策；

• 长期记忆：通过向量数据库实现持久化存储，涵盖跨会话用户偏好、历史任务经验、常用工具调用规则、故障处理方案等，为后续任务提供经验复用与优化依据。

3. 规划模块

负责将用户抽象目标转化为具体可执行步骤，核心流程包含两步：

• 任务分解：将复杂任务拆解为粒度适中的子任务序列，明确各子任务的依赖关系、优先级、执行标准（如"先调用搜索工具获取基础数据，再通过代码解释器计算分析"）；

• 反思与修正：实时接收执行反馈，评估中间结果是否符合预期，若出现偏差（如工具调用失败、结果不达标），立即调整后续规划步骤，避免无效执行。

4. 工具使用

Agent与外部系统、资源交互的核心接口，突破纯语言生成的能力边界，工具类型分为两类：

• 通用工具：涵盖搜索、代码解释器、数学计算、文件I/O等基础工具，满足常规任务需求；

• 特定工具：支持API调用、数据库查询、业务系统（如CRM/ERP）操作等定制化工具，适配专业场景任务。

5. 执行引擎

承接大脑与规划模块的决策，负责具体落地执行，核心职责包括：按步骤调用指定工具、处理工具返回结果（格式标准化、无效信息过滤）、将结果反馈至大脑与记忆模块，同时监控执行过程中的异常，确保任务闭环推进。

三、Agent的主流架构

当前AI Agent主流设计范式分为三类，各有优劣与适用场景：

1. ReAct（Reasoning + Acting）

核心理念：将推理与行动交错迭代，形成"思考-行动-观察"的闭环循环，无需提前生成完整计划，边思考边执行。优点是思路清晰、易于调试，灵活性强，能快速响应执行中的异常与新信息；缺点是依赖单次推理质量，存在陷入无限循环的风险，适用于动态性强、需求边界模糊的任务。

2. Plan-and-Execute

核心理念：严格区分规划与执行两个阶段，先耗时生成完整详细的计划，再按计划逐步执行。优点是对长周期、目标明确的复杂任务效率更高，目标感强；缺点是早期规划错误会导致全流程偏差，灵活性差，难以适配动态场景。

3. Multi-Agent Collaboration

核心理念：构建多个具备专属角色与专长的Agent，通过协作解决单一Agent难以应对的跨领域复杂问题。协作模式包括角色扮演、相互评审、流水线作业等；优点是能处理高度复杂任务，结果质量更优；缺点是系统设计复杂，Agent间协调成本高，运维难度大。

4. 主流架构对比

为更清晰区分三种范式的适配场景与优劣，以下从核心特性、关键优势、主要不足、适用场景四个维度进行对比：

架构范式	核心特性	关键优势	主要不足	适用场景
ReAct	推理与行动交错迭代，无预设完整计划，循环推进	灵活性强，易调试，能快速响应异常与新信息	依赖单次推理质量，存在无限循环风险	动态性强、需求边界模糊、需实时适配的任务
Plan-and-Execute	规划与执行阶段分离，先制定完整计划再落地	目标感强，对长周期、目标明确任务效率高	早期规划错误影响全局，灵活性差	流程固定、目标清晰、无频繁动态调整的任务
Multi-Agent Collaboration	多角色Agent协同，分工协作解决复杂问题	可处理跨领域复杂任务，结果质量更优	系统设计复杂，协调与运维成本高	跨领域、高复杂度、需多专长协同的任务

四、Kilo的核心运行流程

Kilo采用基于原生工具调用的流式迭代执行模式，与标准ReAct架构有所不同。核心特征是LLM通过结构化工具调用与系统交互，而非传统的"思考文本+行动标签"模式。

1. 核心运行流程

用户输入任务
│
├── Task 初始化
│   ├── 构建系统提示词（SYSTEM_PROMPT）
│   └── 加载工具集（基于 Mode 配置）
│
├── 流式执行循环
│   ├── 1. 构建请求消息
│   │   └── 合并用户输入、历史消息、上下文
│   │
│   ├── 2. 发起 API 流式调用
│   │   └── 实时接收 LLM 响应流
│   │
│   ├── 3. 解析工具调用
│   │   └── 识别工具名称和参数
│   │
│   ├── 4. 执行工具
│   │   └── 调用工具并获取结果
│   │
│   └── 5. 判断继续条件
│       ├── 完成（attempt_completion）→ 结束
│       ├── 工具调用 → 返回步骤1（循环）
│       └── 需用户确认 → 暂停等待
│
└── 任务完成
    ├── 保存会话历史（apiConversationHistory）
    └── 持久化状态到磁盘

核心机制：LLM在流式响应中返回工具调用请求，系统执行工具后将结果反馈给LLM，LLM基于结果决定下一步行动，如此循环直至任务完成或需要用户介入。

2. 核心组件

Provider（提供者层）：统一的API调用接口，支持50+模型提供商，采用流式处理实时接收响应，兼容Native和XML两种工具调用协议。

Tools（工具层）：内置工具（文件读写、代码编辑、命令执行、浏览器操作等）、MCP工具（集成外部服务）、自定义工具，不同模式配置不同工具集。

Context（上下文管理）：会话历史存储完整消息记录，接近token限制时自动触发智能压缩（优先AI总结，降级滑动窗口截断），文件追踪避免重复读取，支持@mentions等方式注入上下文。

Mode（模式系统）：预设Architect/Coder/Debugger等模式，每个模式有特定的系统提示词、行为规范和工具配置，适配不同场景需求。