1. 从概念图到能跑的 Agent为什么你学完 13 个名词还是写不出代码AI Agent 这个词现在几乎出现在每一场技术分享里但真正动手时你会发现一个尴尬的现实Transformer、Prompt Engineering、Fine-tuning、RAG、Function Calling、MCP、Skill、Memory、Context Engineering、Reasoning Planning、Agent、Multi-Agent、Harness Engineering 这 13 个概念单看每个都懂串起来就乱。更麻烦的是概念懂了不等于工程能跑——你打开编辑器面对一个空目录不知道第一个文件该写什么。这篇内容面向刚接触 Agent 开发的读者目标很明确把上面这 13 个知识点当作骨架在 Function Calling 和 Multi-Agent 这两个最需要真实 API 调用的环节引入 TaoToken 统一 Key/API 通道交付一份可以直接复制的settings.json与config.toml配置骨架再配一个连通性验证动作。读完你手里应该有一个能跑起来的最小 Agent 工程而不是一张只存在于笔记里的概念图。先说清楚这 13 个概念在工程里的位置避免你继续把它们当成并列的名词。Transformer 是底座决定了模型怎么处理上下文Prompt Engineering、Context Engineering、Memory 属于“喂什么给模型”的层面RAG、Function Calling、MCP、Skill 属于“模型能拿到什么外部能力”的层面Reasoning Planning、Agent、Multi-Agent、Harness Engineering 属于“怎么组织决策与执行”的层面Fine-tuning 则是另一条改参数的路线和前面这些外挂式手段是两条路。理解这个分层你才知道配置该写在哪一层。我试过把 13 个概念按“是否需要在配置文件里体现”重新分类结论是真正需要落到配置里的其实只有四类——模型接入信息、工具/函数声明、记忆与检索的存储地址、多 Agent 的编排参数。其余概念更多影响你写提示词和组织代码结构的思路。所以下面的配置骨架会围绕这四类展开而不是把 13 个名词都塞进一个文件。2. TaoToken 前置统一 Key 与 API 通道在 Agent 工程里的角色在 Function Calling 和 Multi-Agent 实战里最容易被低估的工程问题是“接入层”。单 Agent 调一个模型还好一旦进入 Multi-Agent你可能需要多个角色分别调用模型如果每个角色都维护一套 Key 和 endpoint配置会迅速失控。TaoToken 在这里的作用是提供统一的 Key 与 API 通道让你在settings.json和config.toml里只维护一份接入信息多个 Agent 角色共享。需要先明确一点TaoToken 是合规的 API 接入服务不是所谓的中转也不涉及任何网络访问工具。你只需要在配置里填官网申请的 Key 和官方 API 地址即可。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时不要画蛇添足。为什么强调“统一 Key”这件事因为在 Multi-Agent 场景下你通常会有一个主管 Agent 负责规划若干子 Agent 负责执行。如果每个子 Agent 用不同 Key额度、限流、日志都会分散排查问题时非常痛苦。统一 Key 之后你可以在一个地方看到所有角色的调用情况这对刚入门的读者尤其重要——你还没到需要精细分账的阶段先让系统跑通比什么都强。另外Function Calling 的本质是模型与工具之间的通信协议它输出的是结构化参数真正执行工具的是你的程序。这意味着接入层只需要保证模型能稳定返回结构化 JSON剩下的工具执行逻辑完全在你自己的代码里。TaoToken 提供的统一通道正好满足这个需求你不需要为每个工具单独配置模型接入工具声明和模型接入是解耦的。如果你后续要长期做编码类 Agent 或复杂编排可以关注 Coding Plan 相关入口如果只是想先验证模型对话是否通用模型对话页面即可。这两个入口在后面的 CTA 部分会分别给出这里先记住接入层配置一次后面所有 Agent 角色复用。3. 可复制配置settings.json 与 config.toml 骨架这一节是全文的核心直接给可复制的配置。先给settings.json它适合用在支持 JSON 配置的 Agent 框架里比如一些基于 Node 或 Python 的编排工具。注意把YOUR_TAOTOKEN_KEY替换成你在官网申请的真实 Key。{ provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: YOUR_TAOTOKEN_KEY, timeout_seconds: 60, max_retries: 2 }, models: { default: gpt-4o-mini, planner: gpt-4o, executor: gpt-4o-mini }, function_calling: { enabled: true, tool_choice: auto, parallel_tool_calls: false, strict_schema: true }, memory: { short_term: { type: sliding_window, max_turns: 12 }, long_term: { type: vector, endpoint: http://localhost:8000, collection: agent_memory } }, multi_agent: { mode: hierarchical, max_sub_agents: 3, shared_context: true } }几个参数值得解释。base_url固定为https://taotoken.net/api不要加斜杠结尾也不要加 UTM。tool_choice设为auto让模型自己决定是否调用工具刚入门时不要设成强制调用否则模型会在不需要工具时也硬调。parallel_tool_calls先关掉多工具并行对新手排查不友好等单工具跑通再打开。strict_schema建议开启它能让模型返回的 JSON 更贴合你声明的 schema减少解析失败。再给config.toml它适合用在 Rust 或 Python 生态里偏好 TOML 的框架比如一些本地 Agent 运行时。[provider] name taotoken base_url https://taotoken.net/api api_key YOUR_TAOTOKEN_KEY timeout_seconds 60 max_retries 2 [models] default gpt-4o-mini planner gpt-4o executor gpt-4o-mini [function_calling] enabled true tool_choice auto parallel_tool_calls false strict_schema true [memory.short_term] type sliding_window max_turns 12 [memory.long_term] type vector endpoint http://localhost:8000 collection agent_memory [multi_agent] mode hierarchical max_sub_agents 3 shared_context true两份配置的结构是对应的你可以根据框架选其中一份。这里要提醒一个踩过的坑api_key千万不要提交到 Git 仓库。建议用环境变量注入比如在settings.json里写成api_key: ${TAOTOKEN_API_KEY}然后在启动脚本里 export。很多新手第一次跑通后直接 commitKey 泄露了都不知道。工具声明部分单独说一下因为它对应 Function Calling 这个知识点。你需要在代码里定义工具的名称、描述和参数 schema模型才能识别。一个最小工具声明长这样{ name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如 北京 } }, required: [city] } }模型收到用户请求后如果判断需要查天气会返回一个包含get_weather和{city: 北京}的结构化输出你的程序解析后执行真实查询再把结果回传给模型组织语言。这就是 Function Calling 的完整闭环配置里的function_calling段就是为它服务的。4. 验证请求确认统一 Key 通道真的通了配置写完不验证等于没写。这一节给一个最小连通性验证动作用 curl 直接打 API确认 Key 和通道都正常。注意这是验证模型对话能力不是验证工具执行工具执行依赖你自己的代码。curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 只回复两个字通了} ], temperature: 0 }如果返回的 JSON 里choices[0].message.content包含“通了”说明统一 Key 通道正常。如果返回 401检查 Key 是否复制完整如果返回 404检查base_url是否写成了https://taotoken.net/api而不是别的路径如果超时检查timeout_seconds是否太短。接下来验证 Function Calling 是否可用。把工具声明一起传进去看模型是否返回tool_calls字段curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 北京现在天气怎么样} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ], tool_choice: auto }预期结果是返回的 message 里带tool_calls其中function.name为get_weatherarguments为{city: 北京}这样的 JSON 字符串。拿到这个结果说明你的 Function Calling 链路在接入层已经通了剩下的是在代码里解析并执行。Multi-Agent 的验证稍微复杂一点因为涉及多个角色。最小验证方式是用同一个 Key 连续发两次请求第一次让模型扮演规划者输出步骤第二次把步骤作为输入让模型扮演执行者输出结果。如果两次都正常返回说明统一 Key 支持多角色复用你的multi_agent配置就有意义了。这里不需要真的起多个进程先验证通道复用即可。5. 本篇常见错排查配置、调用与多 Agent 的坑第一个高频错误是base_url写错。有人写成https://taotoken.net/api/带尾斜杠有人写成https://taotoken.net/api/v1这两种都可能导致 404。正确写法就是https://taotoken.net/api路径拼接交给 SDK 或你的请求代码。另外 API 地址不要加 UTM 参数UTM 只用于官网入口统计。第二个错误是 Key 注入失败。如果你在settings.json里写了${TAOTOKEN_API_KEY}但启动时没 export框架会把它当成字面量发出去返回 401。排查方法是打印实际请求头确认Authorization里的 Key 不是占位符。建议在启动脚本里加一行检查Key 为空就直接退出。第三个错误是工具 schema 不合法。parameters必须是合法的 JSON Schematype必须是objectproperties里每个字段要有type。如果 schema 写错模型可能不返回tool_calls或者返回的arguments解析失败。排查时先把 schema 简化到只有一个必填字段跑通后再加。第四个错误是 Multi-Agent 上下文串味。如果你开了shared_context多个子 Agent 会看到彼此的对话历史可能导致角色混乱。刚入门时建议先关掉shared_context让每个子 Agent 独立上下文等编排逻辑稳定后再考虑共享。这也是 Context Engineering 这个知识点在工程里的直接体现上下文不是越多越好过长会分散模型注意力。第五个错误是超时设置过短。Agent 调用工具后需要把结果回传模型再生成回答这一轮往返比普通对话长。timeout_seconds设 60 比较稳妥设 10 很容易在工具执行慢时超时。如果确实需要更快先把工具执行逻辑优化而不是压缩超时。第六个错误是忘记处理tool_calls为空的情况。模型有时会直接回答而不调用工具你的代码必须判断tool_calls是否存在不存在就走普通回复分支。很多新手只写了调用工具的分支遇到模型直接回答就报错。6. 把概念图变成工程下一步该动哪里走到这里你手里应该有了两份可复制的配置、一个连通性验证动作、一份常见错排查清单。13 个概念里Transformer 和 Fine-tuning 你暂时不用动前者是模型内部机制后者是另一条成本更高的路线Prompt Engineering、Context Engineering、Memory 影响你写提示词和组织上下文的方式RAG、Function Calling、MCP、Skill 影响你给模型挂什么能力Reasoning Planning、Agent、Multi-Agent、Harness Engineering 影响你怎么编排决策循环。下一步最值得动手的是把get_weather换成你真实需要的工具比如查数据库、调内部接口、读文件。工具执行逻辑写在你自己的代码里接入层继续复用 TaoToken 的统一 Key。等单 Agent 跑稳再按multi_agent配置起一个规划者和一个执行者验证任务拆分是否合理。如果你在接入或排障过程中卡住优先看 API Keys 和接入文档这两个入口能解决大部分配置问题如果只是想先确认模型对话是否正常用模型对话页面快速验证如果你打算长期做编码类 Agent 或复杂编排Coding Plan 会更合适。统一 Key 配置一次后面所有角色复用这是把 13 个概念真正落到工程里的第一步。
AI Agent 核心概念全景图：从入门到实战的 13 个关键知识点（TaoToken 统一 Key 配置版）
1. 从概念图到能跑的 Agent为什么你学完 13 个名词还是写不出代码AI Agent 这个词现在几乎出现在每一场技术分享里但真正动手时你会发现一个尴尬的现实Transformer、Prompt Engineering、Fine-tuning、RAG、Function Calling、MCP、Skill、Memory、Context Engineering、Reasoning Planning、Agent、Multi-Agent、Harness Engineering 这 13 个概念单看每个都懂串起来就乱。更麻烦的是概念懂了不等于工程能跑——你打开编辑器面对一个空目录不知道第一个文件该写什么。这篇内容面向刚接触 Agent 开发的读者目标很明确把上面这 13 个知识点当作骨架在 Function Calling 和 Multi-Agent 这两个最需要真实 API 调用的环节引入 TaoToken 统一 Key/API 通道交付一份可以直接复制的settings.json与config.toml配置骨架再配一个连通性验证动作。读完你手里应该有一个能跑起来的最小 Agent 工程而不是一张只存在于笔记里的概念图。先说清楚这 13 个概念在工程里的位置避免你继续把它们当成并列的名词。Transformer 是底座决定了模型怎么处理上下文Prompt Engineering、Context Engineering、Memory 属于“喂什么给模型”的层面RAG、Function Calling、MCP、Skill 属于“模型能拿到什么外部能力”的层面Reasoning Planning、Agent、Multi-Agent、Harness Engineering 属于“怎么组织决策与执行”的层面Fine-tuning 则是另一条改参数的路线和前面这些外挂式手段是两条路。理解这个分层你才知道配置该写在哪一层。我试过把 13 个概念按“是否需要在配置文件里体现”重新分类结论是真正需要落到配置里的其实只有四类——模型接入信息、工具/函数声明、记忆与检索的存储地址、多 Agent 的编排参数。其余概念更多影响你写提示词和组织代码结构的思路。所以下面的配置骨架会围绕这四类展开而不是把 13 个名词都塞进一个文件。2. TaoToken 前置统一 Key 与 API 通道在 Agent 工程里的角色在 Function Calling 和 Multi-Agent 实战里最容易被低估的工程问题是“接入层”。单 Agent 调一个模型还好一旦进入 Multi-Agent你可能需要多个角色分别调用模型如果每个角色都维护一套 Key 和 endpoint配置会迅速失控。TaoToken 在这里的作用是提供统一的 Key 与 API 通道让你在settings.json和config.toml里只维护一份接入信息多个 Agent 角色共享。需要先明确一点TaoToken 是合规的 API 接入服务不是所谓的中转也不涉及任何网络访问工具。你只需要在配置里填官网申请的 Key 和官方 API 地址即可。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时不要画蛇添足。为什么强调“统一 Key”这件事因为在 Multi-Agent 场景下你通常会有一个主管 Agent 负责规划若干子 Agent 负责执行。如果每个子 Agent 用不同 Key额度、限流、日志都会分散排查问题时非常痛苦。统一 Key 之后你可以在一个地方看到所有角色的调用情况这对刚入门的读者尤其重要——你还没到需要精细分账的阶段先让系统跑通比什么都强。另外Function Calling 的本质是模型与工具之间的通信协议它输出的是结构化参数真正执行工具的是你的程序。这意味着接入层只需要保证模型能稳定返回结构化 JSON剩下的工具执行逻辑完全在你自己的代码里。TaoToken 提供的统一通道正好满足这个需求你不需要为每个工具单独配置模型接入工具声明和模型接入是解耦的。如果你后续要长期做编码类 Agent 或复杂编排可以关注 Coding Plan 相关入口如果只是想先验证模型对话是否通用模型对话页面即可。这两个入口在后面的 CTA 部分会分别给出这里先记住接入层配置一次后面所有 Agent 角色复用。3. 可复制配置settings.json 与 config.toml 骨架这一节是全文的核心直接给可复制的配置。先给settings.json它适合用在支持 JSON 配置的 Agent 框架里比如一些基于 Node 或 Python 的编排工具。注意把YOUR_TAOTOKEN_KEY替换成你在官网申请的真实 Key。{ provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: YOUR_TAOTOKEN_KEY, timeout_seconds: 60, max_retries: 2 }, models: { default: gpt-4o-mini, planner: gpt-4o, executor: gpt-4o-mini }, function_calling: { enabled: true, tool_choice: auto, parallel_tool_calls: false, strict_schema: true }, memory: { short_term: { type: sliding_window, max_turns: 12 }, long_term: { type: vector, endpoint: http://localhost:8000, collection: agent_memory } }, multi_agent: { mode: hierarchical, max_sub_agents: 3, shared_context: true } }几个参数值得解释。base_url固定为https://taotoken.net/api不要加斜杠结尾也不要加 UTM。tool_choice设为auto让模型自己决定是否调用工具刚入门时不要设成强制调用否则模型会在不需要工具时也硬调。parallel_tool_calls先关掉多工具并行对新手排查不友好等单工具跑通再打开。strict_schema建议开启它能让模型返回的 JSON 更贴合你声明的 schema减少解析失败。再给config.toml它适合用在 Rust 或 Python 生态里偏好 TOML 的框架比如一些本地 Agent 运行时。[provider] name taotoken base_url https://taotoken.net/api api_key YOUR_TAOTOKEN_KEY timeout_seconds 60 max_retries 2 [models] default gpt-4o-mini planner gpt-4o executor gpt-4o-mini [function_calling] enabled true tool_choice auto parallel_tool_calls false strict_schema true [memory.short_term] type sliding_window max_turns 12 [memory.long_term] type vector endpoint http://localhost:8000 collection agent_memory [multi_agent] mode hierarchical max_sub_agents 3 shared_context true两份配置的结构是对应的你可以根据框架选其中一份。这里要提醒一个踩过的坑api_key千万不要提交到 Git 仓库。建议用环境变量注入比如在settings.json里写成api_key: ${TAOTOKEN_API_KEY}然后在启动脚本里 export。很多新手第一次跑通后直接 commitKey 泄露了都不知道。工具声明部分单独说一下因为它对应 Function Calling 这个知识点。你需要在代码里定义工具的名称、描述和参数 schema模型才能识别。一个最小工具声明长这样{ name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如 北京 } }, required: [city] } }模型收到用户请求后如果判断需要查天气会返回一个包含get_weather和{city: 北京}的结构化输出你的程序解析后执行真实查询再把结果回传给模型组织语言。这就是 Function Calling 的完整闭环配置里的function_calling段就是为它服务的。4. 验证请求确认统一 Key 通道真的通了配置写完不验证等于没写。这一节给一个最小连通性验证动作用 curl 直接打 API确认 Key 和通道都正常。注意这是验证模型对话能力不是验证工具执行工具执行依赖你自己的代码。curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 只回复两个字通了} ], temperature: 0 }如果返回的 JSON 里choices[0].message.content包含“通了”说明统一 Key 通道正常。如果返回 401检查 Key 是否复制完整如果返回 404检查base_url是否写成了https://taotoken.net/api而不是别的路径如果超时检查timeout_seconds是否太短。接下来验证 Function Calling 是否可用。把工具声明一起传进去看模型是否返回tool_calls字段curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_TAOTOKEN_KEY \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 北京现在天气怎么样} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ], tool_choice: auto }预期结果是返回的 message 里带tool_calls其中function.name为get_weatherarguments为{city: 北京}这样的 JSON 字符串。拿到这个结果说明你的 Function Calling 链路在接入层已经通了剩下的是在代码里解析并执行。Multi-Agent 的验证稍微复杂一点因为涉及多个角色。最小验证方式是用同一个 Key 连续发两次请求第一次让模型扮演规划者输出步骤第二次把步骤作为输入让模型扮演执行者输出结果。如果两次都正常返回说明统一 Key 支持多角色复用你的multi_agent配置就有意义了。这里不需要真的起多个进程先验证通道复用即可。5. 本篇常见错排查配置、调用与多 Agent 的坑第一个高频错误是base_url写错。有人写成https://taotoken.net/api/带尾斜杠有人写成https://taotoken.net/api/v1这两种都可能导致 404。正确写法就是https://taotoken.net/api路径拼接交给 SDK 或你的请求代码。另外 API 地址不要加 UTM 参数UTM 只用于官网入口统计。第二个错误是 Key 注入失败。如果你在settings.json里写了${TAOTOKEN_API_KEY}但启动时没 export框架会把它当成字面量发出去返回 401。排查方法是打印实际请求头确认Authorization里的 Key 不是占位符。建议在启动脚本里加一行检查Key 为空就直接退出。第三个错误是工具 schema 不合法。parameters必须是合法的 JSON Schematype必须是objectproperties里每个字段要有type。如果 schema 写错模型可能不返回tool_calls或者返回的arguments解析失败。排查时先把 schema 简化到只有一个必填字段跑通后再加。第四个错误是 Multi-Agent 上下文串味。如果你开了shared_context多个子 Agent 会看到彼此的对话历史可能导致角色混乱。刚入门时建议先关掉shared_context让每个子 Agent 独立上下文等编排逻辑稳定后再考虑共享。这也是 Context Engineering 这个知识点在工程里的直接体现上下文不是越多越好过长会分散模型注意力。第五个错误是超时设置过短。Agent 调用工具后需要把结果回传模型再生成回答这一轮往返比普通对话长。timeout_seconds设 60 比较稳妥设 10 很容易在工具执行慢时超时。如果确实需要更快先把工具执行逻辑优化而不是压缩超时。第六个错误是忘记处理tool_calls为空的情况。模型有时会直接回答而不调用工具你的代码必须判断tool_calls是否存在不存在就走普通回复分支。很多新手只写了调用工具的分支遇到模型直接回答就报错。6. 把概念图变成工程下一步该动哪里走到这里你手里应该有了两份可复制的配置、一个连通性验证动作、一份常见错排查清单。13 个概念里Transformer 和 Fine-tuning 你暂时不用动前者是模型内部机制后者是另一条成本更高的路线Prompt Engineering、Context Engineering、Memory 影响你写提示词和组织上下文的方式RAG、Function Calling、MCP、Skill 影响你给模型挂什么能力Reasoning Planning、Agent、Multi-Agent、Harness Engineering 影响你怎么编排决策循环。下一步最值得动手的是把get_weather换成你真实需要的工具比如查数据库、调内部接口、读文件。工具执行逻辑写在你自己的代码里接入层继续复用 TaoToken 的统一 Key。等单 Agent 跑稳再按multi_agent配置起一个规划者和一个执行者验证任务拆分是否合理。如果你在接入或排障过程中卡住优先看 API Keys 和接入文档这两个入口能解决大部分配置问题如果只是想先确认模型对话是否正常用模型对话页面快速验证如果你打算长期做编码类 Agent 或复杂编排Coding Plan 会更合适。统一 Key 配置一次后面所有角色复用这是把 13 个概念真正落到工程里的第一步。
