企业官网建设流程全解析

如果你最近在接触智能体开发，大概率会遇到一个困惑：网上的教程和框架越来越多，Dify、Coze、扣子、多智能体、A2A 协议、向量数据库、知识库……每一样看起来都重要，每一样都值得学，但真到自己动手做一个编码智能体时，反而不知道从哪里下笔。

这个现象的根源，不是“智能体太难”，而是很多人把智能体想复杂了。一个真正能跑起来的编码智能体，最核心的部分其实非常朴素：一条明确的指令、一个能推理的模型、一组工具，再加上一个把这三者串起来的循环。其他所有概念，都是在这些核心要素上做的增强和包装。

这篇文章就来拆解“最简智能体”的核心架构。我会以 Pi Agent 这类强调极简路线的编码智能体为背景，先讲清楚核心架构到底由哪些部分组成，再给出一套可以直接运行的最小代码示例，最后补充工程落地时必须注意的排查方法和最佳实践。

读完这篇文章，你能获得三样东西：第一，对智能体核心架构建立清晰的认知，不再被各种框架名词带偏；第二，一套绕过复杂框架、用几十行代码就能跑通的最小 Agent 循环；第三，把最小实现推向生产环境时，应该优先补哪些工程能力。

1. 为什么“最简”反而难：智能体开发的两极化现状

现在的智能体开发领域，明显分成两种极端。

一种极端是“平台拖拽派”。这类开发者习惯使用可视化平台，通过创建工作流、配置知识库、连接插件来搭建智能体。优点是上手快，不需要写太多代码；缺点也很明显：平台封装得太厚，一旦遇到平台能力之外的场景，比如需要自定义一个特殊的工具调用策略，或者要精细控制模型的每一次推理过程，就会非常吃力。而且平台之间的生态是割裂的，今天在 A 平台搭的东西，明天很难迁移到 B 平台。

另一种极端是“框架堆砌派”。这类开发者知道底层原理重要，于是从 LangChain、LlamaIndex 开始学，再到各种 Agent 框架，每引入一个依赖，项目就要多一层抽象。最终代码确实写出来了，但框架本身带来的学习成本和排错成本，已经超过了 Agent 逻辑本身的复杂度。

真正的问题在于，很多人在还没理解智能体核心架构之前，就被工具链淹没。我们需要回到一个基本问题：一个智能体，哪怕是最简的形式，它由哪些东西组成？只有先把这个问题的答案固定下来，再去谈平台、框架、多智能体协作，才不会迷失方向。

回答这个问题的关键，就是理解 Agent Loop。无论 Pi Agent、Hermes、OpenCode、Codex 这类编码智能体的实现细节有多大差异，它们的内部都运行着一条基本循环：模型观察当前状态、决定调用哪个工具、执行工具并拿到结果、把结果交还给模型继续推理，直到任务完成。

2. Agent 到底在解决什么问题：核心架构的功能底座

在拆解架构之前，有必要先分清两个容易混淆的概念：普通的大模型对话，和智能体任务执行。

普通的对话系统，是一个“问答闭环”。用户提问，模型回答，交互结束。模型的能力边界停留在“生成文本”，不会去操作外部系统。

智能体系统，是一个“行动闭环”。模型不仅要理解用户的意图，还要把意图拆解成若干步骤，每一步都可能调用工具，比如执行 Shell 命令、读写文件、搜索网页、调用 API。工具返回的结果会被重新送回模型，模型再判断下一步怎么做，直到满足终止条件。

区别在哪里？区别在于模型是否被放在了“循环”里。

没有循环，模型只是一个文本生成器。有了循环，模型才成为一个决策中枢。这正是智能体核心架构的本质：它不是某一个模型，也不是某一种工具，而是一套把模型、工具、上下文组织起来的运行机制。

从工程视角看，这套机制至少承担四个功能底座：

很多初学者只盯着“如何接入大模型 API”这一个点，以为拿到 API 就算会做智能体了。事实上，API 只是推理底座，真正的智能体工程难点，在后三个功能上。

顺便回答一个常见的疑问：智能体和 RAG 有什么区别？很多人把两者混为一谈。RAG 解决的是“怎么让模型了解私有知识”，它侧重信息的检索和增强；智能体解决的是“怎么让模型完成一系列操作”，它侧重决策和行动。两者可以结合，但不是同一个概念。一个完整的智能体可能需要 RAG 来获取知识，但 RAG 本身不等于智能体。

对 Pi Agent 这类编码智能体来说，它真正解决的痛点，是让大模型不只是“帮你写一段代码”，而是能够主动分析项目结构、找出错误、修改文件、运行测试、根据测试结果迭代修复。这一步跨越，靠的正是完整 Agent 循环。

3. 最简智能体核心架构五要素

把智能体核心架构再往细拆，可以分为五个要素。缺了任何一个，都不能称为完整的智能体。

3.1 指令系统：告诉模型要做什么

指令系统对应系统提示词（System Prompt）和任务描述。它决定了模型的行为边界。

在同一套模型和同一种工具集下，指令系统不同，智能体表现出的行为差异会非常大。比如，你可以通过指令限定“只允许修改指定目录下的文件”，也可以要求模型“每次修改前必须解释意图，再执行操作”。

编码智能体通常还会内置大量领域相关的指令，这就是最近经常提到的“Skill”。Pi Agent 这类智能体强调编码 Skill，本质上是把特定编程任务的专家级指令预置到系统中，让模型在处理这类任务时不需要从零推理。

这里要澄清一个容易踩的坑：不要让指令系统承载它不该承载的所有责任。很多人以为只要把提示词写得足够详细，模型就会完全按预期执行。实际上，指令只是约束，真正保证执行质量的，是后续的工具设计、循环限制和验证机制。

3.2 模型推理：决策中枢

模型是智能体的“大脑”。它负责理解指令、分析当前状态、决定下一步动作。模型的选择会直接影响整个智能体的上限。

在 Pi Agent 的架构里，模型并不是越复杂越好，而是“够用就好”。对于代码生成、函数调用这类任务，模型需要具备比较强的指令跟随能力和工具调用能力。有些开发者会发现，同一个 Agent 框架，换一个模型后效果差距很大，这通常不是因为框架变了，而是因为不同模型对工具调用的格式化输出遵循程度不同。

模型在 Agent Loop 中处于中心位置：工具执行结果最终要交还给它做新一轮判断。因此，模型的可控性、延迟、上下文长度，都是架构选型时需要考虑的因素。

这里需要区分一个概念：Agent 的智能不只在模型推理里，也有一部分体现在“循环如何被组织”。打个比方，模型像是员工，Agent 框架像是公司流程。好的员工搭配混乱的流程，效率同样低下；反过来，流程清晰但员工能力不足，任务也完不成。这恰恰是理解核心架构关键的地方：你优化的不只是某个单一组件，而是整个链路。

3.3 工具集：从“只会说”到“能够做”

工具集是智能体与外部世界交互的接口。编码智能体最常用的工具包括：

• 文件读写工具
• 命令行执行工具
• 代码检索工具
• 测试运行工具
• 版本管理工具

工具设计的好坏，直接影响智能体的可用性。这里有两条基本原则。

第一是工具粒度要适中。工具太泛，比如一个“执行任意命令”的工具，模型可以做到所有事，但也会失去控制边界，容易出现不可预期的副作用；工具太细，比如每个操作都拆成一个工具，模型每次决策时面临的选项过多，推理负担会变大，反而更容易选错。

第二是工具返回信息要有结构性。工具返回的不能只是一段模糊文本，最好包含结构化状态标记，比如“文件是否存在”“命令退出码是多少”“测试失败了多少条”。模型依赖这些状态信息做下一步判断，信息越准确，决策就越可靠。

在实践中不少团队容易进入一个误区：工具越强大越好，越多越好。真实情况是，工具集应该遵循最小化原则。一个能解决目标任务的工具集，外加必要的安全边界，就足够了。每多一个工具，就是给模型增加一份决策负担，也增加了提示词被错误利用的潜在风险。

3.4 记忆与上下文：让对话连续

短期记忆充当工作记忆区，存储当前任务内的对话历史、状态快照和中间结果。编码智能体在工作时，往往需要经历多轮推理：分析文件、修改代码、运行测试、继续修复，整个链条中模型都要记住自己之前做了什么，才能保持逻辑一致。这些内容一般通过把历史信息拼接到模型上下文里来实现。

长期记忆则负责跨任务的信息沉淀。比如团队编码规范、项目历史决策、常见问题修复经验，可以存成外部知识源，在需要时通过检索注入上下文。很多企业把内部文档放到向量数据库中，再和 AI 应用结合，本质上是为智能体提供长期记忆。

不过对于“最简智能体”来说，记忆部分不需要一开始就做得特别复杂。先用短期记忆跑通主流程，当项目积累到一定规模，再引入外部存储。过早引入向量数据库，会让核心架构变得臃肿，不利于理解和排错。

3.5 Agent Loop：连接决策与执行的循环

最后这个要素，是整个核心架构的灵魂。

Agent Loop 的完整循环通常包含以下阶段：

1. 接收用户任务。
2. 将任务结合系统提示词、历史上下文、工具信息一起交给模型。
3. 模型输出决策，可能是一次文本回答，也可能是一个工具调用请求。
4. 如果生成文本回答，说明任务完成，直接返回给用户。
5. 如果是工具调用请求，解析工具名和参数，执行工具。
6. 将工具执行结果作为新的上下文，回到步骤 2 继续运行。
7. 设置最大循环次数，避免无限执行。

这个循环看似简单，实则是工程设计的核心决策点。循环里每一步都可能出错：模型输出了格式不正确的工具调用、工具执行超时、工具返回了大量无用信息撑爆上下文……这些都需要在循环设计阶段预先考虑。

很多开源编码智能体的核心差异，恰恰在这个循环细节上。为什么有的 Agent 用起来“很聪明”，有的“很笨”？一部分原因是模型能力差异，另一部分是这个循环的设计差异，包括：结果如何截断、错误如何反馈给模型、多步失败后如何恢复。这通常是各框架最值得读源码的部分。

4. Pi Agent 的极简设计理念

Pi Agent 进入学习者视野的原因，并不是因为它有大模型训练层面的突破，而是在产品取向上走了另一条路：极简。

从它的命名和定位来看，“最简智能体”并不代表功能弱，而是代表一种架构哲学：能用简单机制解决的事情，不用复杂框架解决；能通过核心循环完成的任务，不引入额外依赖；能靠代码直接控制的分支，不依赖可视化工作流引擎。

这一点对智能体开发者很有启发意义。当前社区里存在着一种趋势，把一个本来简单的事情越做越复杂。构建智能体时，很多人会不由自主地想加入记忆模块、加入外部知识库、加入复杂的提示词策略、加入多智能体协作。但对一个刚开始进入智能体开发的人来说，这种叠加通常会产生反效果，因为变量太多，一旦出问题，根本不知道是哪一层引起的。

Pi Agent 的极简理念，某种程度上是对这种“复杂化惯性”的纠偏。它建议开发者先把最简单的主干撑起来：指令、模型、工具、循环。等主干跑通了，再根据实际需求，逐步增加记忆、知识检索和多智能体协作。

从材料中还可以看到，编码智能体领域的可选产品很多，比如 OpenCode、Codex、Hermes 等，社区里也经常争论“哪个更好用”。我的判断是：不要急着问“哪个 Agent 最厉害”，而要先问“我是否已经理解了它们共享的核心架构”。如果你理解了 Agent Loop，任何一款编码智能体在你眼里都会变成一个可拆解、可修改、可排查的工程系统，而不是一个黑盒。

这也解释了为什么学智能体开发，不一定要从最重的框架开始。从一个迷你 Agent 开始，反而更容易建立正确的架构直觉。

5. 环境准备与前置条件

要把最小核心架构跑起来，需要准备以下环境。具体的版本号请以你实际安装的版本为准，不建议在没有明确需求时追求最新版本。

5.1 运行环境建议

• 操作系统：Windows、macOS、Linux 均可。本文示例采用 Python 编写，在三个系统上都能直接运行。
• Python：建议使用 Python 3.9 及以上版本。如果你是在 Windows 上部署这类工具，建议先确认 Python 已经加入系统 PATH，避免出现“python 不是内部或外部命令”的问题。
• 依赖库：为了让示例尽量轻量，我会用requests来调用模型服务，其他核心逻辑全部使用 Python 标准库。

安装依赖的命令：

pip install requests

如果你希望体验更完整的编码智能体功能，而不是只理解核心架构，可以尝试安装 Pi Agent 本体，也可以选用其他你熟悉的编码智能体工具。安装方式会随版本迭代变化，建议以官方文档为准。本文后续示例的目的是让你“理解并复现最小核心循环”，而不是替代 Pi Agent 的官方实现。

5.2 模型服务与密钥配置

示例需要一个可调用的推理模型。这里有两种选择。

第一种是调用云端大模型 API。你需要提前在模型服务商平台创建 API Key，并确认该模型支持工具调用或函数调用。将密钥写入环境变量，推荐命名如下：

export LLM_API_KEY="你的密钥"

Windows 用户可以使用：

set LLM_API_KEY=你的密钥

第二种是使用本地模型服务。你可以在本地运行 Ollama 等推理服务，然后通过http://localhost:11434这类地址调用模型。本地部署的好处是数据不出内网，隐私更可控。

无论哪种方式，请务必遵守服务商的使用条款和当地法律法规，不对模型服务做未授权的访问。不要把密钥硬编码在代码里，更不要把密钥提交到公开仓库。

6. 最小核心架构代码示例

在这一节，我给出一个完整的极简版本 Agent Loop 代码。它不依赖任何框架，目的是展示核心架构的关键流程。看完代码，你再去读任何框架源码，都会有豁然开朗的感觉。

6.1 项目结构

mini_agent/ ├── core.py # 最简 Agent 循环 ├── tools.py # 工具注册与实现 ├── config.yaml # 配置文件 └── main.py # 运行入口

6.2 配置文件

配置文件用来管理模型参数、系统提示词和循环策略，避免把配置散落在代码里。

# 文件路径：mini_agent/config.yaml model: name: "your-model-name" temperature: 0.0 max_tokens: 2048 agent: system_prompt: | 你是一个编码助手智能体。 当需要执行操作时，请严格按以下格式返回工具调用： {"tool_name": "工具名", "tool_args": {"参数名": "参数值"}} 在你的回复中不要添加多余解释。 max_steps: 10

这里的temperature设置为 0，是为了让智能体的决策尽量确定。编码任务通常需要稳定输出，不适合太高的随机性。

6.3 核心循环实现

""" 文件路径：mini_agent/core.py 最简智能体核心：围绕 Agent Loop 组织的最小实现。 说明：这是一个教学示例，用于理解核心架构，不是 Pi Agent 的官方实现。 """ import json from typing import Callable, Dict class ToolRegistry: """工具注册中心：管理智能体可以调用的工具列表。""" def __init__(self): self._tools: Dict[str, Dict] = {} def register(self, name: str, description: str, handler: Callable): self._tools[name] = {"description": description, "handler": handler} def list_tools(self) -> str: lines = [f"{name}: {info['description']}" for name, info in self._tools.items()] return "\n".join(lines) def call(self, name: str, args: dict): tool = self._tools.get(name) if not tool: return f"错误：未知的工具 {name}" try: return tool["handler"](**args) except Exception as exc: return f"工具执行异常: {exc}" class MiniAgent: """ 最简智能体。 它接收一个用户任务，在循环中反复让模型决策，直到任务完成或到达最大步数。 """ def __init__(self, model_name: str, system_prompt: str, max_steps: int = 10): self.model_name = model_name self.system_prompt = system_prompt self.max_steps = max_steps self.tool_registry = ToolRegistry() self.messages = [{"role": "system", "content": system_prompt}] def _chat(self, user_content: str) -> str: """ 向模型发送一次请求并返回文本结果。 这里是一个占位实现，请替换成你自己的模型调用。 """ # 示例直接返回一个工具调用，便于演示 return json.dumps({"tool_name": "echo", "tool_args": {"text": user_content}}) def run(self, user_task: str): self.messages.append({"role": "user", "content": user_task}) for step in range(1, self.max_steps + 1): print(f"===== Step {step} =====") last_message = self.messages[-1]["content"] model_reply = self._chat(str(last_message)) try: parsed = json.loads(model_reply) except json.JSONDecodeError: print(f"模型最终输出: {model_reply}") return model_reply tool_name = parsed.get("tool_name") tool_args = parsed.get("tool_args", {}) if not tool_name: print(f"模型最终输出: {model_reply}") return model_reply print(f"调用工具: {tool_name}, 参数: {tool_args}") result = self.tool_registry.call(tool_name, tool_args) print(f"工具结果: {result}") self.messages.append({"role": "assistant", "content": model_reply}) self.messages.append({"role": "tool", "content": str(result)}) print("错误：超过最大循环次数，任务未完成。") return None

在真实环境中，_chat方法需要替换为实际的模型服务调用。这里用固定返回来说明循环的形态。注意看run方法内部的循环逻辑：每次模型返回文本时，先尝试解析是否为一个工具调用；如果是，就执行工具并把结果追加到消息列表，再进入下一轮；如果不是，说明模型认为任务已经完成，直接输出结果。

6.4 注册工具

接下来定义两个演示工具，并注册到ToolRegistry。

""" 文件路径：mini_agent/tools.py 演示工具：echo 和 add。 """ from core import ToolRegistry def echo(text: str) -> str: return f"echo: {text}" def add(a: int, b: int) -> int: return a + b def build_registry() -> ToolRegistry: registry = ToolRegistry() registry.register( name="echo", description="原样返回传入的文本，用于测试。", handler=echo, ) registry.register( name="add", description="计算两个整数的和。", handler=add, ) return registry

这里的echo工具可以让你直观看到 Agent Loop 的反馈机制。真实编码智能体中的工具会比这个复杂得多，但注册、调用、返回结果这一标准流程是完全相同的。

6.5 运行入口

最后写一个入口文件，把配置和代码串起来。

""" 文件路径：mini_agent/main.py 运行示例： python main.py "请执行 echo 测试" """ import yaml from core import MiniAgent from tools import build_registry def load_config(path: str) -> dict: with open(path, "r", encoding="utf-8") as file: return yaml.safe_load(file) if __name__ == "__main__": config = load_config("config.yaml") agent_config = config["agent"] model_config = config["model"] agent = MiniAgent( model_name=model_config["name"], system_prompt=agent_config["system_prompt"], max_steps=agent_config["max_steps"], ) registry = build_registry() agent.tool_registry = registry task = input("请输入任务: ") agent.run(task)

由于主流程引用了yaml，需要提前安装依赖：

pip install pyyaml requests

如果你的 Python 环境里没有yaml模块，上面这行会把 PyYAML 一并安装好。在这个教学实现中，我故意把_chat方法写成固定返回，目的是先跑通循环。你理解循环之后，下一步再替换成真实模型调用。

实际调用模型时，可以把_chat方法替换为类似这样的代码结构：

import requests def _chat_real(self, content: str) -> str: headers = {"Authorization": f"Bearer {API_KEY}"} payload = { "model": self.model_name, "messages": self.messages, "temperature": 0, } response = requests.post(API_URL, headers=headers, json=payload, timeout=60) response.raise_for_status() return response.json()["choices"][0]["message"]["content"]

这里我特意不写死API_URL和API_KEY，因为不同服务商的接口地址和鉴权方式差异很大。你只要遵循一个原则：模型返回的内容，要么是最终回答，要么是合格的工具调用 JSON，Agent Loop 就能正常工作。

7. 运行结果与效果验证

完成代码编写后，按以下顺序验证。

先确认项目目录结构完整，然后在项目根目录运行：

cd mini_agent python main.py

输入任务请执行 echo 测试，预期输出类似：

===== Step 1 ===== 调用工具: echo, 参数: {'text': '请执行 echo 测试'} 工具结果: echo: 请执行 echo 测试 ===== Step 2 ===== 模型最终输出: {"tool_name": "echo", "tool_args": {"text": "请执行 echo 测试"}} 错误：超过最大循环次数，任务未完成。

看到这个输出，说明 Agent Loop 已经成功跑通。不过它也暴露了一个问题：如果模型每次固定返回同一个工具调用，循环就永远不会终止。真实智能体需要通过“最大步数”和“终止输出”两个机制来结束任务。

在真实场景中，验证 Agent 是否开发成功，可以从下面几个维度判断：

• 任务是否在有限步数内完成。
• 每步工具调用的参数是否符合预期。
• 工具执行结果是否能被模型正确理解并继续迭代。
• 异常分支是否有明确反馈，而不是静默失败。

如果你把_chat方法替换成了真实模型服务，可以输入这样一个任务来测试：“我的项目里有多少个 Python 文件？如果有，帮我统计每个文件的代码行数。”这需要你的 Agent 具备文件搜索工具。如果还做不到，先回退到最简单的 echo 测试。

运行失败时，第一步看什么？先看命令行是否报错，比如模块导入错误、依赖缺失；再看消息列表是否包含明显的格式问题，比如模型返回了非 JSON 内容，说明解析逻辑需要增强；最后看工具本身是否有问题，可以用 python 直接调用工具函数来单独验证。

8. 常见问题与排查思路

很多人第一次实现 Agent 时，遇到的问题高度相似。这里整理一份排查清单。

以上问题中，最常见的其实是“模型输出不遵循格式”。这个问题在真实开发中会反复出现。细究起来，主要原因通常是三个：模型本身对函数调用格式的遵循能力弱；系统提示词里给的示例不够清晰；或者工具参数里的枚举、类型说明不够明确。解决思路也是对应调整这三个方向，而不是一味更换更大参数的模型。

另一个高频问题是循环不退出。初学者经常以为，只要模型能力够强，它就能自己判断何时结束。但实际上，即使是很强的模型，也可能在复杂任务中反复调用工具。工程上必须用最大步数做硬性兜底，同时允许用户中途中断。编码智能体尤其要注意，因为修改文件的工具一旦陷入错误循环，可能在短时间内产生大量冗余修改。

9. 最佳实践与工程建议

从“最小可运行”到“生产可用”，中间还有很多工程细节。这些细节并不复杂，但决定了系统是否稳定可控。

9.1 提示词工程

系统提示词是智能体的行为准则。建议把提示词作为独立文件管理，纳入版本控制。提示词的内容应该包括：角色定义、工具调用格式、任务完成标准、禁止事项。

每当你发现智能体在一个场景下表现不佳，优先检查提示词是否有歧义或冲突。不要在提示词里堆砌所有话术，保持简洁，便于迭代。一个常见的错误是，把大量业务规则塞进提示词，结果模型在长上下文中迷失，反而忘记关键约束。

9.2 工具设计原则

工具是智能体的手脚，它的质量比数量更重要。建议遵循以下原则：

• 每个工具只做一小件事，职责清晰。
• 认真写工具描述，因为模型依赖描述来决策。
• 参数类型要明确，最好提供取值范围说明。
• 工具返回值要有结构化信息，至少包含成功失败状态。

一个有意思的细节是，模型的工具调用效果和你写的工具描述息息相关。描述写得太模糊，模型就不知道这个工具适合什么问题；描述写得太复杂，模型又可能被误导。这个度需要在实际测试中调整。

9.3 循环保护

生产环境的 Agent 必须有三个保护机制：

1. 最大循环次数。
2. 单次工具执行超时。
3. 危险操作二次确认。

编码智能体在修改文件、执行命令时，尤其需要这类保护。建议在架构中增加“操作策略层”，对高危工具做白名单或授权控制。例如，允许读取文件，但写文件或删除文件需要额外确认。这不仅是安全需要，也是用户体验需要。

9.4 安全与权限

智能体拥有工具调用能力，本质上是把系统权限交给了模型决策。这里必须遵循最小权限原则。

不要给智能体一个拥有全部权限的账号。如果智能体只需要操作某个工作目录，就限定在这个目录内；如果需要调用外部 API，就使用独立的、可撤销的密钥；如果 Agent 要执行 Shell 命令，建议在沙箱容器里运行，而不是直接使用宿主机权限。

这些看似麻烦的限制，能避免大量因误操作引发的严重问题。尤其是当智能体接入企业知识库、数据库或生产环境时，权限控制更是一道必不可少的安全边界。对拿不准的操作，宁可先拒绝，也不要让模型自行判断。

9.5 可观测性

智能体的运行过程是一个多步决策过程，很难用单一日志来分析问题。建议记录完整链路：

• 每一轮的模型请求与响应。
• 每一次工具调用的参数和结果。
• 每一步的耗时。
• 最终任务是否成功完成。

把这些信息结构化落盘，便于复现问题和回归测试。实际开发中，你可能会发现某个 Agent 任务上一次成功、这一次失败，通常是因为模型输出不稳定、工具返回状态变化或上下文差异。缺乏日志，这类问题几乎无法定位。

10. 从最简到生产：下一步学什么

当你能熟练写出、修改并运行一个最简 Agent Loop，说明你已经具备了智能体开发的核心直觉。下一步不需要急着堆框架，而是沿着下面几条线继续深化。

第一，学习多智能体协作。单个 Agent 的能力再强，也存在上下文长度和工具聚焦能力的限制。多智能体架构通过拆分角色，让不同的 Agent 处理不同类型的任务，再通过协作协议组合结果。这个方向的核心仍然是你已经掌握的 Agent Loop，只是多了一层 Agent 之间的通信机制。

第二，深入编码 Skill 与领域化能力。通用智能体只能做通用的事。要让智能体真正服务于某个特定领域，比如后端代码生成、前端页面调试、数据库脚本编写，需要投入时间和精力去沉淀领域技能。这些技能最终会转化为更精确的工具集和更有效的提示词。

第三，建设评测体系。智能体开发中，最容易被忽略的就是测试。和普通软件不同，Agent 的行为带有随机性和多样性，传统断言很难覆盖所有情况。你可以把典型任务整理成评测集，每次修改后跑一遍看通过率。这一步做得越早，后续迭代越稳。

第四，关注行业平台工具。像 Dify、Coze 这类平台降低了智能体应用开发的门槛，它们很适合作原型验证和业务落地；但如果你追求对系统的完全控制，还是需要回到核心架构层，自己掌控循环逻辑。平台工具和核心架构并不冲突，它们是不同阶段的合适选择。

最后，回到智能体学习的起点：不要被术语和框架吓住。智能体的核心架构根本没有多玄妙，它就是一个“模型加循环”的组合。把它理解透，再去看市面上任何一款 Agent 产品，你都多了一双看穿表象的眼睛。

现在最值得做的，不是继续收集工具列表，而是把上面这套最小实现亲手跑一遍，替换成真实模型，注册你自己的工具类，观察它哪里聪明、哪里笨拙。这个从无到有的过程，比阅读一百篇概念文章都更有价值。