简易Agent框架发展史：从工具到智能体的进化

最初，Agent的概念其实很朴素：把预先定义好的一组工具函数提供给大模型，让模型自己去判断该调用哪个、怎么调，应用层拿到工具返回的结果再喂回给模型，模型继续推理——直到问题解决。后来这个“应用层”被统一叫做 harness，但核心逻辑没变。

所以，Agent到底是什么？一个比较严谨的定义是：能够基于环境自主感知、做出决策（比如调用工具）、最终完成预定目标的任务自执行系统。拆开来看，四个关键词很关键：

• 自主：不是靠人一步步喂提示，而是能根据任务目标和当前环境自己做决定；
• 感知：能观察环境的变化和变量，相当于长了一双“眼睛”；
• 工具：Agent干活也好、与环境交互也罢，靠的就是工具——你有什么工具，Agent就有什么能力；
• 目标：所有行为围绕一个预设目标展开，目标达成了，任务才算结束。

基于这些，一个典型的 Agent 会包含这么几个核心模块：

大模型——大脑

基座模型，提供语言理解、推理、生成的基础能力。它是整个 Agent 的中枢神经，所有决策都从这里发出。

角色与人格——行为边界

每个 Agent 都有预设的应答风格、思考方式、身份和行为约束。这就像给 AI 画了一个“人设”，确保输出符合预期场景。

记忆——能做长周期任务的底气

Agent 需要记得昨天发生了什么，才能完成跨天的任务。记忆分两种：一种是围绕本次会话的短期记忆，另一种是适用于所有对话的长期记忆。合适的记忆策略能带来更好的任务追踪和个性化响应。

记忆的存储方式也有多种：向量数据库适合做语义检索和相似召回；知识图谱则擅长结构化实体与关系的存取，能支持精确推理和多步查询；像 open-claw 那种简单粗暴的，直接把记忆存到本地 md 文件里。还有一个很实用的技巧：每次对话后让模型生成一段简短摘要，只保存重点，既省空间又方便后续检索。

工具——能力的边界

不给模型配工具，它顶多就是个 chatbot。工具是模型与环境交互的接口。模型之所以能选对工具，是因为每个工具都有完整的名称、描述、参数和返回值说明——Agent 在推理时根据这些信息来判断该用什么。

常见的工具分几类：信息获取类（查网页、查 API、查数据库）、文件操作类（读写文件、建目录）、代码执行类（跑 Python/SQL/Shell）、通信类（发邮件、发信息、打电话）。工具越丰富，Agent 的能力边界就越宽。

规划——化整为零的智慧

基座模型可以将复杂任务分解为可执行的子步骤，或者分配给子 Agent 去执行。把大任务拆成小步骤，这一步非常考验模型的推理能力。常见的规划模式有：ReAct（边思考边执行）、plan-and-solve（先出完整计划再逐步执行）、Tree of Thoughts（边执行边推理多种可能路径）。

循环——Agent 的呼吸节奏

Agent 的执行本质上是反复循环的过程：感知 → 思考 → 工具执行 → 记忆 → 结果观察 → 再思考……直到任务完成。一个 Agent 就是一个大 loop：从接收用户输入开始，模型思考任务怎么拆、要不要调用工具，如果调用，选哪个，拿到结果继续思考，直到模型认为可以直接回答用户，loop 结束。

这个 loop 把模型、工具、记忆串在一起，决定下一步是继续执行还是输出结果。有的任务可能跑几个小时甚至几天，这时候就需要考虑记忆管理、长任务规划、错误处理、信息压缩、人机协作这些事了。

那么，具体怎么实现一个轻量级的 Agent 呢？我们可以围绕几个关键角度来设计：工具调用、定时任务、记忆系统、多模型兼容、多平台支持。

比如：内核要轻量，支持多种 channel（消息通道），对接 OpenRouter 等各种模型提供商 API，通过 MCP 工具实现代码执行、网络搜索、文件操作，内置 cron 支持周期性提醒和自动化工作流，记忆系统支持持久化和重要上下文保存，skill 采用渐进式加载。所有这些扩展配置通过一个 config.json 搞定，身份通过 agents.md 定义，能力通过 skill 和 tools 扩展。

核心组件有四个：agentLoop、contextBuilder、toolRegistry、agentHook。

• agentLoop：整个 Agent 的心脏，所有逻辑的入口。它负责接收消息 → 构建上下文 → 调用 LLM → 执行工具 → 响应结果，形成一个完整的处理闭环。就像一个指挥官，把各个模块组装到一起，按固定流程运转。

• contextBuilder：负责从多个信源组装完整的 system prompt，让 Agent 知道自己是谁、能做什么、该怎么做。

前三步很好理解。关键在第五步：只把 skill 的名称和描述注入到 prompt 里，而不是把 skill 的全部内容塞进去。当 Agent 决定要用某个 skill 时，再通过 readFile 工具读取对应的 skill.md 内容。这就是 skill 的渐进式披露设计原则。

具体实现上可以采用三级加载系统：

• 第一级：加载元数据。这部分数据永远在 context 中。通过 skillSummary 将所有 skill 的摘要注入 system prompt。Agent 看到的是一份技能清单，知道有哪些工具可用，但不知道具体怎么用。

• 第二级：全文注入。有些技能需要提前把完整内容注入，比如记忆类 skill。在 SKILL.md 的 frontmatter 中标记 always: true，这类 skill 就会完整地注入到 system prompt 里。

• 第三级：按需加载。在 system prompt 里告诉 LLM：需要时可以通过 readFile 方式加载 skill 的详细信息。

这样，Agent 在需要某个 skill 时，会主动调用 readFile 工具读取完整的 SKILL.md，然后按指令执行。一个标准的 SKILL.md 格式如下：

• toolRegistry：管理所有可用工具，提供 JSON Schema 格式的工具定义给 LLM，方便模型在推理过程中选择合适的工具。既可以内置常用工具，也支持自定义。

• agentHook：整个生命周期的钩子。类似 open-claw 的 Hook，在 Agent 的关键生命周期节点插入自定义逻辑。每个方法默认是空的，不执行任何逻辑——这种非侵入式设计让架构既简洁又便于扩展。

agentLoop 每一轮迭代都会按顺序执行这些钩子。

来看一个具体的例子：text-to-sql Agent。

项目结构：

定义工具时，元数据里包含了 name、description、parameters，这些会被 toolRegistry 收集，转成 LLM function calling 的 schema 发给模型。安全校验方面，代码层面强制只允许 SELECT 和 PRAGMA，防止误操作。执行 SQL 时连接数据库，结果限制最多返回 50 行，防止大表撑爆上下文窗口。

组装 Agent 时，通过 config.json 配置，包括 readFile 读取 skill.md、writeFile 写文件、exec 执行 shell 命令、queryDb 只读 SQL。

在 agent.md 里，约束了只使用 queryDb 执行 SQL，不用 exec。

编写 skill 时，把领域最佳实践封装进去，比如如何探索 schema、如何写 SQL、如何纠错。

以上基本上实现了一个 Agent 的基本框架。Agent 会先探索数据库结构，再编写并执行查询，最后生成答案。如果执行过程中报错，Agent 会根据 error recovery skill 的指导自行修正——这就是 skill 的价值：不断把领域经验沉淀下来，封装到 skill 里，Agent 就实现了自进化。

总结一下，实现一个轻量级 Agent 可以遵循几个原则：配置优先（用 config.json 实现配置，避免大量胶水代码）、skill 渐进式披露（三级加载，避免浪费 token 和上下文窗口）、显式注册工具（便于 Agent 选取和调用）、通过 hook 机制提供全生命周期钩子（实现能力的插拔）。

来源：互联网