企业官网建设流程全解析

很多第一次接触 Agent 开发的读者，都会有这样一个感觉：看概念文章和分享视频的时候觉得不过如此，无非是“大模型 + 工具调用 + 循环判断”。可真轮到自己动手，从需求拆解、模型调用、工具设计、上下文管理，再到结果验证和稳定性处理，每一步都可能卡住。市面上讲 Agent 概念的材料很多，但能带着你从零把一套可运行的智能体工具链搭起来的内容却不多。

这篇文章想做一个偏硬核的尝试：不依赖某个重量级 Agent 框架，而是从最底层开始，亲手设计并实现一个轻量级智能体工具链。我们会一起拆解 Agent 的核心运行循环，实现工具注册与调用、记忆管理、结果验证，并讨论工程化落地时真正值得关注的坑。

读完这篇文章，你应该能回答这几个问题：Agent 开发的门槛到底在哪里；一个可运行的 Agent 工具链最少包含哪几个模块；以及你自己动手时，应该从哪里开始、如何设计、如何排错。

1. 这篇文章真正要解决的问题

很多人学 Agent 的时候会陷入两种极端：一种是一直在学概念，看了大量“什么是 Agent 智能体”“什么是框架与编排”的科普文章，却从来没有跑通过自己的代码；另一种是直接套用某个 Agent 框架，把配置填好、跑一个 demo，然后就结束了。等换一个业务场景，因为不懂内部机制，稍微出点问题就不知道怎么排查。

这篇文章走的是第三条路：不依赖重型框架，从零搭建一套最小可用的智能体工具链。这套工具链会包含以下核心能力：

• 接收用户任务，并转化为系统提示和初始消息。
• 调用大模型进行规划和决策。
• 根据模型输出，解析出工具调用请求。
• 执行工具函数，把结果返回给模型。
• 维护短期记忆和上下文长度控制。
• 设定最大轮次，防止无限循环。
• 记录完整的执行轨迹，方便排查问题。

这个过程中，你会真实理解 Agent 框架底层做的事情，而不是停留在“Agent 就是大模型加工具”的粗浅认知上。以后再去看 LangChain、Microsoft Agent Framework、Codex Agent 这类产品，或者阅读 Agent 框架源码，理解成本会低很多。

什么样的人最适合读这篇文章？如果已经有 Python 基础，写过简单的 API 调用，但还没有完整实现过一个 Agent 项目，那么这篇文章就是为你准备的。如果你已经在用某个 Agent 框架，但总觉得是“黑盒”，希望搞清楚推理循环、工具调用和上下文管理内部发生了什么，这篇文章也能提供不少有价值的信息。

2. Agent 与工具链的基础概念

2.1 什么是 Agent

Agent 智能体，广义上是指能够感知环境、做出决策并采取行动的自主系统。在 LLM 语境里，Agent 通常指以大型语言模型为“大脑”，通过规划、工具调用和记忆机制，完成复杂任务的程序系统。

有一个容易被忽略的点：Agent 不是让你训练一个模型，也不是简单封装一个 Chat API。Agent 的核心价值在于“行动能力”。模型本身只能生成文字，它不能查天气、不能操作数据库、不能调用电商订单接口。Agent 通过工具调用让模型能够对外部世界产生影响，并在工具返回结果后继续推理，直到任务完成。

传统问答系统的工作方式是“用户问一句，模型答一句”。Agent 的工作方式是“模型根据目标生成动作，执行动作，观察结果，再决定下一步动作”，这个过程反复循环，直到达成目标或达到终止条件。这正是 Agent 和普通 Chatbot 的本质区别。

2.2 为什么叫“工具链”

“工具链”这个词从编译器领域借过来。写 C/C++ 时，编译器只是其中最核心的一环，真正要把一份源码变成可运行的程序，还需要链接器、汇编器、标准库、构建系统和调试工具，这些组合在一起才叫编译工具链。比如给 Keil 这样的 IDE 配置外部的 GCC 工具链，实际上就是在更换整个编译链路中负责代码生成的那个核心组件。

Agent 领域很像。大模型是“编译器内核”，但要让 Agent 在真实业务里跑起来，还需要周围一整套配套组件：模型接入层负责屏蔽不同模型的 API 差异；工具层负责把业务能力封装成模型可调用的函数；记忆层负责管理上下文和长期知识；执行循环负责把“模型决策”变成“真实动作”；可观测性负责记录每次决策和工具调用，出了问题能回放。这一整套东西，就是 Agent 的工具链。

理解了这一点，就会明白为什么只调一个 Chat API 不能叫 Agent 开发，也明白为什么社区里讨论“Agent 开发学习路线”时，总有经验丰富的前辈强调要重视工具链建设，而不只是模型选择。

2.3 Harness、Skill 与 Agent 的关系

搜索热词里经常出现几个相近概念，这里一次说清楚。

Harness 可以理解为“运行 Agent 的外壳或者执行环境”。它负责管理 Agent 的执行循环、消息流转、工具调用生命周期、错误处理和终止条件。可以把它类比为 Web 应用里的 Spring MVC 框架——它不关心你的业务细节，但决定了请求怎么进来、路由怎么走、异常怎么处理。

Skill 则代表“Agent 可以调用的某项能力封装”，本质上是一组工具函数和对应调用说明的集合。一个“获取天气”的 Skill 可能包括天气 API 的调用代码、参数模型、返回结果解析逻辑，以及“什么时候该用这个工具”的描述。

Agent 是宏观智能体，Harness 是 Agent 的执行载体，Skill 是 Agent 的技能组件。搭建工具链时，第一步要搭的是 Harness，也就是执行循环本身；第二步才是按业务能力封装 Skill。很多初学者一上来就想实现特别复杂的技能，结果核心循环跑不通，这是本末倒置。

2.4 Agent 记忆的分类

记忆也是 Agent 开发的热门话题，搜索热词里“agent记忆”出现频率很高。工程上建议至少区分两层记忆。

工作记忆指当前任务进行中需要保留的对话上下文和中间结果，通常放在消息列表里，由 Agent 执行循环管理。由于大模型上下文窗口有限，工作记忆需要做裁剪、摘要或丢弃。

长期记忆指跨会话的业务知识、用户偏好、历史结论，一般存放于向量数据库、KV 存储或普通数据库中，在合适的时机通过检索注入到上下文中。自己搭工具链时，优先把工作记忆做好，长期记忆先按需求做最小实现，不必过度设计。

3. 环境准备与前置条件

开始写代码之前，先把环境准备好。以下为本项目的运行环境建议，具体版本请以实际项目为准，本文重点演示通用思路。

• 操作系统：Windows / macOS / Linux 均可。
• Python 3.9 及以上版本。
• pip 包管理工具。
• 网络环境：可访问大模型 API 服务。
• 一个可用的模型 API Key，使用 OpenAI 兼容接口格式。
• 建议准备一个虚拟环境，避免依赖冲突。

创建并激活虚拟环境：

python -m venv agent_env source agent_env/bin/activate

Windows 环境激活命令为：

agent_env\Scripts\activate

安装依赖：

pip install requests python-dotenv

这里没有采用重量级框架，只使用 requests 发送模型请求，python-dotenv 用于读取本地环境变量。选择最小依赖的原因，是为了让你看清 Agent 工具链的底层逻辑，而不是被框架封装掩盖。后续如果有需要，可以再把代码迁移到任何主流框架上。

项目目录结构规划如下：

agent-toolchain/ ├── .env # 环境变量文件（API Key） ├── config.py # 读取配置 ├── tools.py # 工具定义与注册 ├── memory.py # 记忆管理 ├── agent.py # 核心执行循环 ├── main.py # 入口脚本与演示 └── requirements.txt # 依赖清单

4. 工具链架构设计与核心流程拆解

4.1 整体架构

一套轻量级 Agent 工具链，我按职责拆成四个模块，每个模块只做一件事：

这种分层设计的好处是隔离变化。某个模块需要调整时，不会牵连其他模块。例如以后想把模型从 A 厂商切换到 B 厂商，只需要在配置层和模型请求函数里做少量修改，工具层和记忆层基本不用动。

4.2 核心执行循环

这是整个 Agent 工具链的心脏。执行循环的基本逻辑是这样的：

1. 拼接系统提示、记忆消息、用户新请求，形成完整的消息列表。
2. 把消息列表发送给大模型。
3. 模型可能返回两种结果：直接给出最终答案，或者输出一个工具调用指令。
4. 如果是工具调用指令，则解析出工具名和参数，调用对应工具函数，把结果作为一条新消息加入列表。
5. 再次调用模型，让它基于工具结果继续推理。
6. 反复执行步骤 3 到 5，直到模型不再调用工具，或达到最大迭代轮次。

这个循环把一个“复杂的多步任务”拆成了“模型决策 + 工具执行 + 结果反馈”的简单迭代。重点是让每次循环中模型都能看到新的信息，从而做出下一次更准确的决策。

4.3 工具注册与调用

为了让模型能够调用工具，工具层必须做两件事：一是提供工具的描述信息，比如工具名称、功能说明、参数类型和是否必填；二是提供真实的执行函数。

工具的说明要写得足够清楚，因为模型是“读”着这些描述决定什么时候调用、传什么参数的。描述越模糊，模型乱调用的概率越高。一个常见的错误是工具描述里不写适用条件，导致模型在根本不该用工具的场景调用了工具。

工具函数本身要尽量做成无状态、纯函数式。同样的参数传入，返回结果应该确定且可预测。这样不仅方便测试，也让整个 Agent 的行为更容易维护。

4.4 记忆管理

自己搭工具链时，上下文管理是一个容易忽略但很致命的点。多轮工具调用后，消息列表会快速增长，很快接近模型的上下文窗口上限。

Memory 模块需要提供两个基本能力：追加消息；在消息过多时做裁剪。

最简单但实用的裁剪策略是：保留系统提示、保留最近 N 轮对话消息、把中间过长的历史消息替换成一段摘要。这样牺牲了一部分长程信息，但保证了 Agent 不会因超长报错。等需要更强记忆时，再引入向量检索和摘要记忆，设计思想是一样的。

5. 完整示例代码实现

下面我会逐个文件搭建这套工具链。示例代码使用 OpenAI 兼容接口格式，模型请求会发送到/v1/chat/completions，你可以根据自己的 API 服务商调整OPENAI_BASE_URL。所有代码均为最小演示实现，核心目的是展示 Agent 工具链的工作机制。

5.1 配置文件

# config.py import os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY = os.getenv("OPENAI_API_KEY", "") OPENAI_BASE_URL = os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1") MODEL_NAME = os.getenv("MODEL_NAME", "gpt-4o-mini") SYSTEM_PROMPT = """你是一个能够调用工具完成任务的中文智能体。 当你需要获取额外信息时，请根据工具说明调用工具。 每次只能输出一个工具调用，格式如下： <tool_call>{"name": "工具名", "arguments": {"参数名": "参数值"}}</tool_call> 基于工具结果继续推理。如果任务已经完成，直接输出最终答案，不要再调用工具。""" MAX_ITERATIONS = 5

.env文件示例：

OPENAI_API_KEY=sk-your-api-key OPENAI_BASE_URL=https://api.openai.com/v1 MODEL_NAME=gpt-4o-mini

这里要特别提醒：千万不要把包含真实 Key 的.env文件提交到 Git 仓库。建议把.env写入.gitignore，项目中只保留.env.example作为模板。

5.2 工具层实现

# tools.py import json # 工具注册表 TOOL_REGISTRY = {} def register_tool(name, description, parameters): """注册工具的装饰器工厂""" def decorator(func): TOOL_REGISTRY[name] = { "name": name, "description": description, "parameters": parameters, "func": func, } return func return decorator @register_tool( name="get_weather", description="获取指定城市的当前天气信息，当用户询问天气时使用", parameters={ "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，例如 北京"} }, "required": ["city"], }, ) def get_weather(city: str): # 演示用，真实项目中可以替换为天气 API 调用 weather_data = { "北京": "晴，25 度", "上海": "小雨，22 度", "广州": "多云，28 度", } data = weather_data.get(city, f"暂无 {city} 的天气数据") return json.dumps({"city": city, "weather": data}, ensure_ascii=False) @register_tool( name="calculator", description="执行简单的四则运算表达式，当用户需要数学计算时使用", parameters={ "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，例如 1 + 2 * 3"} }, "required": ["expression"], }, ) def calculator(expression: str): # 演示用，仅支持安全的数学表达式 # 实际项目请使用更严谨的表达式解析库，不要直接用 eval try: safe_expression = expression.replace("^", "**") result = eval(safe_expression, {"__builtins__": {}}, {}) return json.dumps({"expression": expression, "result": result}, ensure_ascii=False) except Exception as e: return json.dumps({"error": f"计算失败: {str(e)}"}, ensure_ascii=False) def get_tool_schemas(): """生成用于模型提示的工具描述列表""" schemas = [] for tool in TOOL_REGISTRY.values(): schemas.append({ "name": tool["name"], "description": tool["description"], "parameters": tool["parameters"], }) return schemas def execute_tool(name: str, arguments: dict): """根据工具名执行工具""" if name not in TOOL_REGISTRY: return json.dumps({"error": f"未找到工具: {name}"}, ensure_ascii=False) func = TOOL_REGISTRY[name]["func"] try: return func(**arguments) except TypeError as e: return json.dumps({"error": f"工具参数错误: {str(e)}"}, ensure_ascii=False) except Exception as e: return json.dumps({"error": f"工具执行异常: {str(e)}"}, ensure_ascii=False)

代码里有两点值得注意：第一，工具描述和参数结构是给模型读的，写得越明确，模型调用就越准确；第二，示例中的calculator使用了eval，但这只是演示。实际项目中不要直接对模型生成的表达式执行eval，这是严重的安全隐患。更好的做法是用aSTE库或者其他安全的表达式解析方案，并且一定要在沙箱或受控环境中运行外部输入。

5.3 记忆层实现

# memory.py class Memory: """简单的消息记忆管理器""" def __init__(self, max_messages: int = 20): self.messages = [] self.max_messages = max_messages def add(self, role: str, content: str): self.messages.append({"role": role, "content": content}) self._trim_if_needed() def get_messages(self): return self.messages def _trim_if_needed(self): # 超过阈值时，丢弃最旧的中间消息，保留系统提示和最近消息 if len(self.messages) <= self.max_messages: return keep_count = self.max_messages - 2 self.messages = [self.messages[0]] + self.messages[-keep_count:] def clear(self): self.messages = []

这个 Memory 类非常朴素，但它抓住了记忆管理的核心：防止上下文无限增长。它的裁剪策略是“丢最旧的中间消息”，在演示场景已经够用。真实项目中可以把“被丢弃的历史”替换成摘要消息，这是下一步的优化方向。

5.4 Agent 核心执行循环

# agent.py import json import re import requests from config import OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_NAME, SYSTEM_PROMPT, MAX_ITERATIONS from memory import Memory from tools import get_tool_schemas, execute_tool TOOL_CALL_PATTERN = re.compile(r"<tool_call>(.*?)</tool_call>", re.S) class Agent: def __init__(self): self.memory = Memory() self.memory.add("system", SYSTEM_PROMPT) def _call_model(self, messages): """调用 OpenAI 兼容接口""" headers = { "Authorization": f"Bearer {OPENAI_API_KEY}", "Content-Type": "application/json", } payload = { "model": MODEL_NAME, "messages": messages, } # 工具描述直接拼进系统提示里，让模型知道有哪些工具 tool_schemas = get_tool_schemas() payload["messages"][0]["content"] += "\n\n可用工具:\n" + json.dumps(tool_schemas, ensure_ascii=False) response = requests.post( f"{OPENAI_BASE_URL}/chat/completions", headers=headers, json=payload, timeout=60, ) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"] def run(self, user_input: str): """执行 Agent 主循环""" self.memory.add("user", user_input) current_messages = self.memory.get_messages() for step in range(1, MAX_ITERATIONS + 1): print(f"[Step {step}] 调用模型进行推理...") response_text = self._call_model(current_messages) print(f"[Step {step}] 模型输出: {response_text}") tool_match = TOOL_CALL_PATTERN.search(response_text) # 没有工具调用，认为任务完成 if not tool_match: self.memory.add("assistant", response_text) return response_text # 解析工具调用 try: tool_call = json.loads(tool_match.group(1)) tool_name = tool_call["name"] tool_args = tool_call.get("arguments", {}) except Exception as e: error_msg = f"工具调用解析失败: {str(e)}" print(f"[Step {step}] {error_msg}") self.memory.add("assistant", response_text) self.memory.add("user", error_msg) continue print(f"[Step {step}] 调用工具: {tool_name}, 参数: {tool_args}") tool_result = execute_tool(tool_name, tool_args) print(f"[Step {step}] 工具结果: {tool_result}") # 把中间过程写入记忆，供后续推理使用 self.memory.add("assistant", response_text) self.memory.add("tool", tool_result) current_messages = self.memory.get_messages() return "已达到最大执行轮次，任务未能完成，请简化任务或检查工具调用。"

Agent.run是这个工具链的核心。它不断经历“模型推理 -> 判断是否调用工具 -> 执行工具 -> 把结果写回上下文”的循环，直到模型不再调用工具，或者轮次耗尽。每一轮都打印运行日志，这是后面排查和验证的关键。

5.5 入口与运行

# main.py from agent import Agent def main(): agent = Agent() while True: user_input = input("请输入你的问题（输入 exit 退出）: ").strip() if user_input.lower() == "exit": break if not user_input: continue print("=" * 50) result = agent.run(user_input) print("=" * 50) print("最终结果:", result) print("=" * 50) if __name__ == "__main__": main()

运行之前，先把依赖安装好：

pip install -r requirements.txt

requirements.txt内容：

requests==2.31.0 python-dotenv==1.0.0

然后启动：

python main.py

6. 运行结果与效果验证

6.1 预期运行过程

输入问题时，Agent 会打印每一步的推理和工具调用过程。例如输入：

北京今天天气怎么样？顺便算一下 123 * 45

预期会看到类似下面的执行轨迹：

请输入你的问题（输入 exit 退出）: 北京今天天气怎么样？顺便算一下 123 * 45 ================================================== [Step 1] 调用模型进行推理... [Step 1] 模型输出: <tool_call>{"name": "get_weather", "arguments": {"city": "北京"}}</tool_call> [Step 1] 调用工具: get_weather, 参数: {'city': '北京'} [Step 1] 工具结果: {"city": "北京", "weather": "晴，25 度"} [Step 2] 调用模型进行推理... [Step 2] 模型输出: <tool_call>{"name": "calculator", "arguments": {"expression": "123 * 45"}}</tool_call> [Step 2] 调用工具: calculator, 参数: {'expression': '123 * 45'} [Step 2] 工具结果: {"expression": "123 * 45", "result": 5535} [Step 3] 调用模型进行推理... [Step 3] 模型输出: 北京今天天气晴朗，气温 25 度。123 * 45 的结果是 5535。 ================================================== 最终结果: 北京今天天气晴朗，气温 25 度。123 * 45 的结果是 5535。 ==================================================

注意，由于不同模型对提示的遵循程度不同，实际输出格式可能略有差异，但执行流程应该保持一致：先调用天气工具，再调用计算器工具，最后汇总答案。

6.2 如何判断成功

判断这套工具链是否真正跑通，可以从以下几个维度验证：

• 模型能够在需要时输出工具调用标记，而不是自顾自地编造答案。
• 工具调用能被正确解析，工具名称和参数都能对应上。
• 工具结果能回到模型上下文中，并影响最终回答。
• 连续多步工具调用场景下，Agent 不会丢失前面的状态。
• 多轮对话场景下，Agent 能记住当前会话之前的上下文。
• 达到最大轮次时会安全退出，而不是死循环或直接崩溃。

6.3 建立简单的评测集

工具链搭好之后，不要只测试一个例子就收工。建议准备一个小的评测集，里面包含几类典型任务：

把这些评测用例写成脚本，每次修改工具链代码后都跑一遍。这是 Agent 工程化最重要的一步，它决定了你的工具链是“能跑 demo”还是“能稳定迭代”。

7. 常见问题与排查思路

自己从零实现 Agent 工具链的过程中，会踩很多坑。以下是高频问题与排查方法。

排查 Agent 问题时，最重要的一点是：必须能看到完整的执行轨迹。强烈建议把每一轮的模型输入消息、模型输出、工具调用指令、工具返回结果全部打印或写入日志。很多问题只有回放执行轨迹才能定位。“Agent execution terminated due to error”这类报错，如果不看执行轨迹，基本无从下手。

8. 工程化最佳实践与安全边界

8.1 工具函数的权限控制与安全边界

这是 Agent 生产化最核心的一条。模型输出的工具调用本质上是不可信的输入，因为模型可能生成错误的参数，也可能被恶意提示词引导调用危险工具。安全设计应该遵循最小权限原则：

• 工具函数只暴露业务需要的最小能力，不要把一个完整的万能函数暴露给 Agent。
• 涉及数据库写入、文件删除、数据修改、资金操作等敏感操作，必须设置二次确认或人工审批机制。
• 不要让 Agent 直接执行任意 Shell 命令或 Python 代码，尤其是当工具的输入来自外部用户时。
• 对工具执行结果要做校验，避免把异常数据直接注入到模型上下文中。
• 在测试环境中验证工具行为，再考虑部署到生产环境，并准备回滚方案。

8.2 工具描述与参数设计

工具并不是越多越好。工具描述写得不好，模型会在不必要时调用；工具粒度太细，模型需要多步才能完成任务，增加错误概率。建议按“业务能力”而不是“API 粒度”来封装工具。一个查询订单状态的工具，应该封装好订单查询的完整逻辑，而不是把好几个底层参数直接暴露给模型。

在设计工具时还要注意参数约束。必填参数、可选参数、参数类型、取值范围这些信息都应该体现在参数 Schema 中。模型面对空泛的参数描述时，常常会脑补一个不存在的值传给工具。

8.3 日志、可观测性与进度打印

一个生产级 Agent 工具链，必须能够回答三个问题：它为什么做出这个决策？它调用了什么工具？卡在了哪一步？建议使用结构化日志记录每个环节的耗时和状态，包括模型调用耗时、工具执行耗时、模型返回内容、工具返回内容。

在本项目的Agent.run方法中，已经加入了[Step N]形式的过程输出。真实项目中可以把这些信息输出到日志文件或可观测性平台，便于事后分析和优化。

8.4 配置管理

Model 名称、API Base URL、API Key、最大轮次、超时时间等参数，都不应该硬编码在代码里。建议统一走配置管理：本地开发用.env文件，生产环境用环境变量或配置中心。配置修改后，应该能够通过热更新生效，而不是每次改配置都要重新发版。

8.5 成本控制与限流

Agent 的一个隐藏成本问题是：一次用户请求可能触发多次模型调用。一个复杂任务可能调用模型 5 到 10 次，成本会线性增长。工程上可以做下面几件事：

• 对单次任务的模型调用轮次设置上限。
• 对单用户请求的频率做限流。
• 对模型输入输出 token 数量做统计和监控。
• 提供任务级别的取消机制，让用户在 Agent 卡住时能主动终止。
• 优先使用性价比高的模型处理简单任务，复杂推理再切换到更强的模型。

8.6 从最小实现走向框架封装

自己手写完这套代码之后，再做技术选型时会有完全不一样的判断力。你会发现主流 Agent 框架解决的核心问题，和这篇文章里的执行循环是类似的，只是它们做了更多的抽象、兼容性和生态集成。你在实际项目中不一定需要自己维护工具链，但了解底层机制能让你选择框架时有更清晰的依据，也能在框架不满足需求时做出合理的扩展。

9. 总结与后续学习方向

这篇文章没有直接带你去读某个框架的文档，而是先把 Agent 工具链的最小组成拆开，从配置、工具、记忆、执行循环四个模块，带你从零搭了一套可以运行的智能体。到这里，你应该已经理解了一个 Agent 程序的核心运行机制：模型负责推理决策，工具负责真实行动，记忆负责上下文管理，循环负责把两者连接起来，直到任务完成。

下一步的实践建议很简单：把这份代码跑通，然后改造成你自己的第一个 Agent 项目。你可以给工具层增加一个新的业务工具，比如查询数据库、调用内部接口、操作文件等，然后写一个针对你的业务场景的评测集，跑几轮，看它在哪里会出错。

如果你准备继续深入 Agent 开发，可以沿着下面几个方向走：

• 深入看主流 Agent 框架的源码，理解它们如何实现多工具编排、重试和异常恢复。
• 研究多 Agent 协作和 Agent Graph，尝试把一个复杂任务拆成多个角色。
• 完善记忆系统，把简单的裁剪策略升级为摘要记忆和向量检索记忆。
• 建立更完整的评测体系，包括单任务成功率、工具调用准确率、上下文注入准确率和端到端耗时。
• 关注 Agent 安全测试，包括提示注入、工具滥用、越权访问等与 AI 应用密切相关的新风险。

这套代码只是一个起点，但它的价值在于，你亲手写过之后，Agent 对你不再是一个黑盒。以后无论用什么框架、什么模型、什么工具链，你都知道那层“魔法”背后发生的是什么。建议把这篇文章收藏备用，等你开始改造自己的第一个 Agent 项目时，再对照着一步步来，会顺手很多。