企业官网建设流程全解析

1. 从符号推理到 ReAct：Agent 到底解决了什么问题

大模型智能体（LLM Agent）这个词在 2026 年已经不算新鲜，但很多人第一次接触时还是会把它和「套了系统提示词的聊天机器人」混为一谈。我先把结论放前面：Agent 的本质是让模型从「一问一答」变成「多步骤自主执行」，而 ReAct 范式是这条路上第一个真正跑通的工程方案。理解它，你才能看懂后面 Cursor、Claude Code、Manus 这些产品为什么长成现在这样。

先看一个最直观的对比。普通 LLM 应用是这样的：用户问「北京今天天气怎么样」，模型回答「今天晴，25 度」——如果模型知识截止到去年，这个答案就是编的。Agent 则是：用户说「帮我查下北京天气，如果下雨就提醒我带伞」，Agent 会先思考「我需要调用天气工具」，然后执行工具调用，拿到真实数据，再判断「今天有雨」，最后输出「今天北京有雨，记得带伞」。区别在于：普通应用是单次推理，Agent 是「思考—行动—观察」的循环，直到目标完成。

这个循环不是凭空冒出来的。1995 年 Russell 和 Norvig 在《人工智能：一种现代方法》里就把 Agent 分成四类：简单反射型、基于模型型、基于目标型、基于效用型。今天的 LLM Agent 基本落在后两类——它有目标（完成任务），也有偏好（选最优路径）。但传统 Agent 的规则是人写死的，遇到规则外的情况就傻眼；LLM Agent 用模型的推理能力替代了人写规则，灵活了，但也带来了新问题：模型会推理错，会幻觉，会陷入死循环。

2022 年 10 月普林斯顿的 ReAct 论文就是来解决这个矛盾的。它发现纯推理（Chain-of-Thought）容易胡说，因为模型只在脑子里想，不去验证；纯行动（Act-only）又容易盲目执行，因为没有规划。ReAct 的做法是让两者交替：每次行动前先想清楚为什么，行动后观察结果再决定下一步。这个「Thought → Action → Observation」的循环，后来成了几乎所有 Agent 框架的底层骨架。

你可能会问，这跟 Function Calling 有什么关系？关系很大。ReAct 论文发表时，工具调用还得靠提示词「骗」模型输出特定格式，格式错误率很高。2023 年 6 月 OpenAI 推出 Function Calling，模型原生支持结构化工具调用，Agent 的可靠性从 60% 左右跳到 90% 以上。这不是渐进改进，是质变——它让 Agent 从演示玩具变成了能上生产的东西。所以你现在看到的任何 Agent 产品，底层基本都是「ReAct 循环 + Function Calling 工具调用」这套组合。

那为什么还要讲概念起源？因为不理解演进脉络，你调 Agent 时遇到问题就不知道往哪查。比如 Agent 反复调用同一个工具，你得知道这是 ReAct 循环缺少「重复检测」；比如 Agent 规划得乱七八糟，你得知道该上 Plan-and-Execute 模式。这些设计决策都能在历史里找到答案。接下来我先讲怎么用 TaoToken 把模型通道准备好，再给你一份能直接跑的最小 ReAct Agent 配置。

2. TaoToken 前置准备：统一 Key 与 API 通道怎么配

在写 Agent 代码之前，得先把模型接入这关过了。做 Agent 开发最烦的一件事是：你调试时可能想换不同模型对比效果，但每个厂商的 API 格式、鉴权方式、Base URL 都不一样，代码里到处是 if-else。TaoToken 的价值就在这里——它提供统一的 API 通道，你用一套 Key 和一套 Base URL 就能访问多个模型，切换模型只改一个 Model ID 字符串。

先说清楚它是什么：TaoToken 是一个大模型 API 聚合接入服务，官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api 。你注册后在控制台生成 API Key，然后所有请求都走这个统一入口。对 Agent 开发来说，这意味着你的工具调用链、ReAct 循环代码不用为每个模型改一遍。

具体操作步骤。第一步，打开控制台 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，登录后进入 API Keys 页面 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，点「创建新密钥」，复制生成的 Key。这个 Key 只显示一次，建议直接存到环境变量里，别硬编码进代码。

第二步，确认你要用的模型 ID。TaoToken 的模型列表在文档页 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 能查到，常见的有 claude-sonnet-4 系列、gpt-4.1 系列、deepseek 系列等。Agent 场景我建议优先选工具调用能力强的模型，因为 ReAct 循环里工具调用格式错了整个流程就断了。

第三步，配置环境变量。Linux/macOS 下这样写：

export TAOTOKEN_API_KEY="sk-你的密钥" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

Windows PowerShell 用：

$env:TAOTOKEN_API_KEY="sk-你的密钥" $env:TAOTOKEN_BASE_URL="https://taotoken.net/api"

这里有个坑要注意：Base URL 结尾不要带/v1，TaoToken 的入口就是https://taotoken.net/api，SDK 会自动拼接路径。我见过有人写成https://taotoken.net/api/v1然后报 404，排查半天。

第四步，如果你用的是 Claude Code 这类终端工具，它需要单独的配置文件。Claude Code 的配置在~/.claude/settings.json，写入：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的密钥", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

注意这里三个要素必须齐全：Base URL、API Key、Model ID。少任何一个都会报鉴权失败或模型不存在。如果你用 Cline 或 CC Switch 这类插件，配置逻辑一样，都是在设置里填这三项。Cline 的 MCP 配置如果涉及工具服务，也要确保 Base URL 指向 TaoToken 而不是官方地址，否则你的 Key 对不上。

配完之后先别急着写 Agent，用一条 curl 验证通道是否通：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "messages": [{"role": "user", "content": "回复 OK 两个字母"}], "max_tokens": 20 }'

如果返回里有"content": "OK"之类的正常响应，说明通道没问题。如果报 401，检查 Key 有没有复制全；如果报 model not found，检查 Model ID 拼写。这一步过了，再往下写 Agent 代码就顺了。

3. 可复制的最小 ReAct Agent 配置与工具调用链

现在进入正题：写一个能跑的最小 ReAct Agent。我不推荐一上来就用 LangChain 或 AutoGen，那些框架抽象层太厚，出问题你根本不知道是提示词错了还是框架 bug。自己实现一遍 ReAct 循环，代码不到 150 行，但你能彻底搞懂 Agent 在干什么。

先定义工具。Agent 的能力边界由工具决定，我们做两个最基础的：一个查天气，一个算数学。工具定义要符合 Function Calling 的 JSON Schema 格式：

import os import json from openai import OpenAI client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"] ) # 工具1：查天气（模拟实现） def get_weather(city: str) -> str: fake_data = { "北京": "晴，25°C，湿度40%", "上海": "小雨，22°C，湿度85%", "深圳": "多云，28°C，湿度70%" } return fake_data.get(city, f"{city}：暂无数据") # 工具2：计算器 def calculate(expression: str) -> str: try: result = eval(expression, {"__builtins__": {}}, {}) return str(result) except Exception as e: return f"计算错误：{e}" # 工具注册表：名字 -> 函数 TOOL_REGISTRY = { "get_weather": get_weather, "calculate": calculate } # 给 LLM 看的工具描述（JSON Schema） TOOLS_SCHEMA = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名，如北京"} }, "required": ["city"] } } }, { "type": "function", "function": { "name": "calculate", "description": "计算数学表达式，支持加减乘除", "parameters": { "type": "object", "properties": { "expression": {"type": "string", "description": "数学表达式，如 2+3*4"} }, "required": ["expression"] } } } ]

注意TOOL_REGISTRY和TOOLS_SCHEMA是两套东西：前者是实际执行的 Python 函数，后者是给模型看的说明书。模型只认 Schema，执行时你用名字去 Registry 里找函数。这个「描述与执行分离」的设计是 Function Calling 的核心，也是 MCP 协议后来标准化的东西。

接下来是 ReAct 提示模板。System Prompt 要明确告诉模型三件事：你的角色、可用工具、输出格式。我实测下来这个模板比较稳：

REACT_SYSTEM_PROMPT = """你是一个 ReAct 智能体，通过「思考-行动-观察」循环完成任务。 可用工具： - get_weather(city): 查询城市天气 - calculate(expression): 计算数学表达式 工作规则： 1. 每次行动前，先输出你的思考（Thought） 2. 需要调用工具时，使用 function calling 机制 3. 拿到工具结果后，判断是否还需要继续调用 4. 任务完成时，直接给出最终答案，不要再调用工具 5. 如果连续两次调用同一个工具且参数相同，说明陷入循环，请换思路或直接回答 请严格按此流程工作。"""

这个提示词里最关键的是第 5 条——防死循环。ReAct 论文没强调这点，但生产环境里 Agent 反复调同一个工具是最常见的故障。提前在提示词里打预防针，能省很多事。

然后是核心循环：

def run_agent(user_query: str, max_iterations: int = 8): messages = [ {"role": "system", "content": REACT_SYSTEM_PROMPT}, {"role": "user", "content": user_query} ] for i in range(max_iterations): response = client.chat.completions.create( model="claude-sonnet-4-20250514", messages=messages, tools=TOOLS_SCHEMA, tool_choice="auto" ) msg = response.choices[0].message messages.append(msg) # 没有工具调用 → 任务完成 if not msg.tool_calls: return msg.content # 有工具调用 → 逐个执行 for tool_call in msg.tool_calls: name = tool_call.function.name args = json.loads(tool_call.function.arguments) print(f"[第{i+1}轮] 调用 {name}({args})") if name in TOOL_REGISTRY: result = TOOL_REGISTRY[name](**args) else: result = f"错误：未知工具 {name}" print(f"[第{i+1}轮] 结果：{result}") messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": str(result) }) return "达到最大迭代次数，任务未完成"

跑一下：

if __name__ == "__main__": answer = run_agent("北京和上海哪个城市更适合今天出门？先查天气，再算下温差") print("最终答案：", answer)

预期输出会是这样：

[第1轮] 调用 get_weather({'city': '北京'}) [第1轮] 结果：晴，25°C，湿度40% [第1轮] 调用 get_weather({'city': '上海'}) [第1轮] 结果：小雨，22°C，湿度85% [第2轮] 调用 calculate({'expression': '25-22'}) [第2轮] 结果：3 最终答案：北京今天晴，25°C；上海小雨，22°C。温差3°C。上海有雨，北京更适合出门。

这个 Demo 虽然简单，但已经包含了 Agent 的全部核心要素：工具定义、ReAct 提示、循环控制、结果回传。你把这个骨架换成真实工具（数据库查询、API 调用、文件操作），就是一个能用的 Agent 了。

关于配置文件的补充：如果你要把这个 Agent 部署成服务，建议把模型配置抽到单独的config.toml：

[llm] base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" model = "claude-sonnet-4-20250514" max_iterations = 8 temperature = 0.3 [agent] name = "weather-calc-agent" enable_reflection = false

这样切换模型只改model一行，不用动代码。temperature建议设低一点（0.2-0.4），Agent 场景需要稳定输出，不需要创意。

4. 验证请求与成功结果：从单次调用到多轮循环

配置写完了，怎么确认它真的在工作？我分三层验证：先验证模型通道，再验证单次工具调用，最后验证多轮 ReAct 循环。每层都有明确的成功标志，出问题也能快速定位。

第一层，模型通道验证。用上一节的 curl 命令，或者写个最小 Python 脚本：

from openai import OpenAI import os client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"] ) resp = client.chat.completions.create( model="claude-sonnet-4-20250514", messages=[{"role": "user", "content": "只回复：通道正常"}] ) print(resp.choices[0].message.content)

成功标志：输出「通道正常」。如果报AuthenticationError，是 Key 问题；如果报NotFoundError，是 Base URL 或 Model ID 问题。这一步不过，后面都别谈。

第二层，单次工具调用验证。把run_agent的输入改成「北京天气怎么样」，观察日志。成功标志是看到[第1轮] 调用 get_weather({'city': '北京'})和对应的结果，然后模型基于结果给出回答。如果模型直接回答「北京今天晴」而没有调用工具，说明提示词里工具描述不够清晰，或者模型没理解tool_choice="auto"的含义。这时候可以把tool_choice临时改成{"type": "function", "function": {"name": "get_weather"}}强制调用，确认工具链本身是通的。

第三层，多轮循环验证。用「北京和上海哪个更适合出门」这个查询，成功标志是看到至少两轮工具调用（两次 get_weather + 一次 calculate），最后模型综合所有观察结果给出结论。这里有个细节：模型可能在第一轮就同时调用两个 get_weather（并行工具调用），也可能分两轮调用。两种都正常，取决于模型实现。Claude 系列倾向于并行调用，GPT 系列有时会串行。

验证过程中我建议打开详细日志，把每轮的messages打印出来。这样你能看到模型实际收到的上下文长什么样。很多 Agent 问题出在上下文管理上——比如工具结果太长把窗口撑爆，或者tool_call_id对不上导致模型困惑。日志里一眼就能看出来。

一个完整的成功日志应该长这样：

[第1轮] 调用 get_weather({'city': '北京'}) [第1轮] 结果：晴，25°C，湿度40% [第1轮] 调用 get_weather({'city': '上海'}) [第1轮] 结果：小雨，22°C，湿度85% [第2轮] 调用 calculate({'expression': '25-22'}) [第2轮] 结果：3 最终答案：北京晴25°C，上海小雨22°C，温差3°C。上海有雨，建议选北京。

如果你想让 Agent 更聪明一点，可以在循环里加个「反思」环节：当工具返回错误时，让模型先分析错误原因再重试。这个改动很小，就是在result里检测到「错误」关键词时，往 messages 里插一条 system 消息提示模型「上一步失败了，请分析原因后换一种方式」。我试过，对工具调用失败率的降低挺明显。

还有一点：max_iterations别设太大。8 轮对大多数任务够了，设成 20 轮只会让死循环的 Agent 烧更多 Token。配合提示词里的防循环规则，8 轮是个平衡点。

5. 本篇常见错误排查：401、proxy failed、choices 为空怎么解

Agent 开发踩坑是常态，我把最常见的几类错误和排查路径列出来，你对着日志查就行。

错误一：401 Unauthorized / invalid api key

这是最高频的。原因通常有三个：Key 没复制全（前后有空格）、环境变量没生效、Key 被禁用。排查步骤：先echo $TAOTOKEN_API_KEY确认变量有值且无空格；再用 curl 直接带 Key 请求，排除 SDK 干扰；如果 curl 也 401，去控制台 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 确认 Key 状态。注意 Claude Code 这类工具读的是ANTHROPIC_API_KEY而不是TAOTOKEN_API_KEY，变量名写错也会 401。

错误二：local proxy failed / connection refused

这个报错通常出现在你本地配了代理，但代理没启动或端口不对。Agent 请求走的是https://taotoken.net/api，如果你的环境变量里有HTTP_PROXY或HTTPS_PROXY指向一个不存在的本地端口，就会报这个。排查：env | grep -i proxy看有没有残留代理配置，有就 unset 掉。另外检查防火墙有没有拦 443 出站。

错误三：reading 'choices' of undefined / choices 为空

这个错误说明 API 返回了非预期结构。常见原因：Base URL 写成了https://taotoken.net/api/v1（多了一层），导致请求打到了不存在的路径，返回 HTML 错误页而不是 JSON。SDK 解析 HTML 时拿不到choices字段就报这个。解决：Base URL 严格用https://taotoken.net/api，让 SDK 自己拼/v1/chat/completions。另一个可能是 Model ID 不存在，API 返回了错误对象，同样没有choices。打印完整response对象就能看到真实错误信息。

错误四：OAuth / authentication failed（Claude Code 场景）

Claude Code 首次启动会尝试 OAuth 登录官方账号，如果你要用 TaoToken 通道，得跳过 OAuth 直接配 API Key。在~/.claude/settings.json里写全三件套（Base URL + API Key + Model ID），然后启动时如果还弹 OAuth，检查是不是有旧的凭据缓存。删掉~/.claude/下的凭据文件重新配。记住：用第三方通道时不要走 OAuth 流程，直接 API Key 鉴权。

错误五：Agent 死循环 / 反复调用同一工具

这不是报错但比报错更烧钱。表现是日志里同一个工具同样参数出现三次以上。原因：模型没意识到自己在重复，或者工具一直返回空结果。解决：在 System Prompt 里加防循环规则（见第 3 节），在代码里加重复检测——记录最近 N 次调用的(name, args)哈希，重复就强制中断并让模型换思路。另外max_iterations是最后一道防线，别省。

错误六：tool_call_id 不匹配

多轮循环时，如果你手动构造 messages 而tool_call_id和模型返回的对不上，模型会报错或行为异常。解决：永远用模型返回的tool_call.id原样回填，不要自己生成。用 SDK 的 message 对象直接 append 最安全。

排查通用心法：先看 HTTP 状态码，再看响应体，最后看 messages 上下文。90% 的问题在前两步就能定位。剩下 10% 是上下文管理问题，打印完整 messages 基本能看出来。

6. 语义一致 CTA：把 Agent 跑起来之后往哪走

到这里你已经有了一个能跑的最小 ReAct Agent，通道走 TaoToken 统一接入，工具调用链完整，错误排查也有章法了。接下来看你的方向：

如果你主要是在调试模型、对比不同模型在 Agent 场景下的工具调用表现，可以直接用模型对话入口 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite 快速试，不用每次改代码。

如果你要把 Agent 接入 Claude Code 做长期编码任务，配置文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有 Claude Code 的完整接入步骤和 settings.json 示例。

如果你打算做长期的 Agent 开发、跑多轮工具调用和复杂任务编排，Coding Plan 更适合 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，它的额度模型对高频 Agent 调用更友好。

Key 管理和新建密钥还是去控制台 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。API 入口固定是 https://taotoken.net/api ，记住这个地址，所有 SDK 的 base_url 都填它。

最后给个实用建议：Agent 开发最容易被低估的是「工具描述的质量」。模型能不能正确调用工具，八成取决于你的description写得清不清楚。我踩过的坑是工具描述写得太简略，模型要么不调用，要么传错参数。后来我把每个工具的描述都写成「这个工具做什么 + 什么时候用 + 参数含义 + 返回什么」，调用准确率明显上来了。这个细节比换模型管用。