用过 [LangChain]的人很多能讲清agent.run()内部在做什么的人很少。我也是前者。所以这次把框架放一边从零手写了一个 Multi-Agent 客服系统——能查订单、答 FAQ、处理投诉多个 Agent 协作。不是为了取代框架是想搞懂。写完不到 600 行、6 个核心文件最大的收获不是代码是终于能回答那个问题Agent 到底在干什么代码在这里https://github.com/helloworldtang/my-multi-agent-system。下面是我拆出来的东西。一、Multi-Agent这个词是障眼法先祛魅。抛开术语一个 Multi-Agent 系统就四件事调 LLM带超时、重试、日志工具调用让 LLM 能调你的函数ReAct 循环LLM 边想边调工具直到给出答案多 Agent 编排谁干啥、并行还是串行每一件单独看都不复杂。框架的价值在于把它们打包、藏起来、给你一个agent.run()。但藏起来恰恰是问题出了 bug 不知道在哪一层想换个模型、改个工具得先学框架的抽象面试被问讲讲你们的 Agent 架构只能背 API。所以我决定一件件自己写。下面按这个顺序拆。二、function calling不是 AI 的新能力是一份协议很多人觉得 function calling 是AI 学会了调函数。不是。它是一份协议约定你告诉模型有这些工具、参数长这样JSON schema模型回复我要调这个、参数是这些JSON你负责真的执行。模型从来没碰过你的函数是你的代码在派发。理解这一点工具注册就好写了——本质是把 Python 函数签名翻译成 JSON schema。我用一个装饰器自动完成tooldef query_order(order_id: str) - str:“”查询订单状态与物流。Args: order\_id: 订单号如 ORD20240001。 ...装饰器用inspect反射签名 pydantic 校验参数自动生成 OpenAI 的 schema。模型返回{order_id: ORD20240001}pydantic 校验不合法就回灌让它重试。整个 function calling 机制几十行就讲透了。它不是魔法是JSON schema 派发。三、ReAct所谓自主决策就是一个 while 循环ReActReason Act被讲得很玄。其实流程朴素得有点扫兴模型看问题 → 要调工具要执行工具把结果喂回去再问一次不要输出最终答案写成代码核心就是一个循环加一个停止条件for step in range(max_steps):resp llm.chat(conv.to_dicts(), toolstool_schemas)if not resp.tool_calls:return resp.content # 模型不再要工具 → 最终答案for tc in resp.tool_calls:result execute_tool(tc)conv.tool(result, tool_call_idtc.id, nametc.name) # 结果回灌但这里有个反直觉的点ReAct 的难点不在循环在防御。模型会卡死连续调同一个工具、会幻觉参数、会无视你的确认要求。真正花心思的是这些max_steps硬上限防死循环连续 3 次相同调用 → 判卡死强制停止工具执行报错不崩把错误回灌让模型换法子写操作取消订单、退款打requires_confirmation标记先问用户这些才是工程。框架替你做了所以你以为 ReAct 很简单。而且——这些不是 ad-hoc 补丁。先记住它们第六节会收回这条线它们其实是一种更普适思路的具体实现叫给不可靠的 LLM 套一层审视。四、多 Agent最容易过度设计的地方Multi-Agent最容易让人想多。我一开始想上 Actor 模型——每个 Agent 一个消息邮箱搞订阅、序列化、生命周期。写了两小时停下来想了想拓扑发现自己犯傻。我的系统是静态 DAG用户问题 → 路由识别意图 → 挑对应 Agent → 合并回复。这张图是固定的不需要 Actor 那套动态订阅。函数式 fan-out 两个函数就够def fanout(agents, msg):with ThreadPoolExecutor() as ex:return [f.result() for f in [ex.submit(a.run, msg) for a in agents]]def merge(results, llm):if len(results) 1:return results[0].content # 单 Agent零 LLMreturn llm.chat(…).content # 多 Agent一次摘要去重Actor 要 3 倍代码收益为零。这不是偷懒是拓扑分析后的工程判断——我把这个否决理由写进了设计文档因为为什么不用 X往往比用了 X更有信息量。真正用上多 Agent 的地方是路由支持多意图。用户说查下 ORD001顺便问退货政策——既是订单又是 FAQ。老项目if/elif只能选一个必然漏处理。这里返回多意图fan-out 并行两个 Agent再 merge。这才是 Multi-Agent 协作的真实形态不是一堆 Agent 互发消息是一次请求里的并行分工。五、实测function calling 比 prompt 强强多少光讲道理不算数。我跑了 40 个 prompt × 3 种让模型调工具的方式120 次真实调用方式总成功率FAQ 场景原生tools参数95%87%response_formatjson_object95%87%纯 prompt 引导“输出 TOOL: 名字”72%33%这张表回答了一个真问题function calling 到底比 prompt 强在哪、强多少强在可靠性。原生协议和 json_mode 打平95%因为它们都给了模型一个结构化的契约去遵守。纯 prompt 引导在 FAQ 场景只有 33%——模型压根不按你规定的格式随手回你一段自然语言。结论很直接function calling 不是花架子。能用原生协议就别用 prompt 硬模拟。剩下 5% 的失败更有意思——不是协议不稳是模型觉得自己知道答案跳过了检索工具直接回答。这是 RAG 的老难题得靠 prompt 强制检索解决跟换不换调用方式无关。六、LLM 只是跑出结果你还需要一层审视写到这停下来看一个贯穿始终、却很容易被Agent 很酷盖过去的事实实测里那 5% 的失败、72% 的 prompt fallback说的是同一件事——LLM 是概率性的。它会跳过你给的检索工具直接编、会不按你规定的格式输出、会对着一个不存在的订单号一本正经地胡说。跑出结果和结果可靠之间隔着不确定性。这是 LLM 和传统确定性开发的根本边界。你写if x 0:它永远只在 x0 时进分支你让 LLM 判断意图它有概率判错。你不能像信任 if/else 那样信任 LLM 的任何一次单点输出。所以一个能上生产的 Agent 系统光靠 LLM 不够外面必须套一层审视机制。两种形态on-the-loop——系统在回路上监督。不信任单次输出用确定性代码约束它max_steps防死循环、连续调用检测防卡死、JSON schema 校验防乱编参数、工具报错回灌让它重试、路由置信度低于阈值就降级为请您描述清楚一些。LLM 每走一步都被一道闸门拦一下。in-the-loop——人在回路里把关。高风险动作绝不自动执行取消订单、发起退款这些有现实后果的操作打requires_confirmation先回确认取消 ORD001 吗用户点头才放行。把人插进回路用人的确定性兜 LLM 的不确定性。这套把不可靠的 LLM 单元套进一层驾驭的思路有个名字Harness 架构——上下文管理 评估循环 护栏目的就一个让 AI 可靠地完成任务。Claude Code、Cursor 这些工程化做得好的 Agent内核都是 harness它们的好用很大程度来自 harness 做得厚不是模型本身多神。回头看第三节那些防御max_steps、循环检测、错误回灌、requires_confirmation——它们不是临时补丁正是 harness 的具体实现。on-the-loop 是max_steps和校验in-the-loop 是requires_confirmation。每写一层 LLM 调用你都会本能冒出一句它要是出错怎么办然后加一道审视。手写一遍这句话会问到你的肌肉记忆里。而且这些审视现在还是散落在各模块里的——agent.py 管循环、tools.py 管校验、system 管路由阈值。当它们被收敛成一个统一管上下文、评估循环和护栏的运行时层就是harness runtime。Claude Code、Cursor 好用的秘密LangChain 真正在卖的东西很大程度就是这一层——而这层该长什么样手写一遍你就知道了。这也是为什么Multi-Agent 到底比单 Agent 强在哪的答案不在 Agent 数量而在你愿意为不可靠性配多厚的审视层。七、写完之后手写一遍我得到了什么不是以后可以不用框架了。框架依然有价值——省事、有生态、有社区。而是用框架时终于知道每一行在干什么。agent.run()卡住我知道去查哪一层想加个工具我知道在哪注册面试被问架构我能讲清为什么这么设计。还有一条更重要的懂了 LLM 的边界在哪——哪些可以交给概率哪些必须用确定性兜底。这条边界不亲手写一遍看不见。会用和懂之间隔着一条手写的沟。框架帮你跳过了实现但没帮你跳过理解。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
手写一遍 Multi-Agent，我才看清框架到底藏了什么
发布时间：2026/7/22 4:26:03
用过 [LangChain]的人很多能讲清agent.run()内部在做什么的人很少。我也是前者。所以这次把框架放一边从零手写了一个 Multi-Agent 客服系统——能查订单、答 FAQ、处理投诉多个 Agent 协作。不是为了取代框架是想搞懂。写完不到 600 行、6 个核心文件最大的收获不是代码是终于能回答那个问题Agent 到底在干什么代码在这里https://github.com/helloworldtang/my-multi-agent-system。下面是我拆出来的东西。一、Multi-Agent这个词是障眼法先祛魅。抛开术语一个 Multi-Agent 系统就四件事调 LLM带超时、重试、日志工具调用让 LLM 能调你的函数ReAct 循环LLM 边想边调工具直到给出答案多 Agent 编排谁干啥、并行还是串行每一件单独看都不复杂。框架的价值在于把它们打包、藏起来、给你一个agent.run()。但藏起来恰恰是问题出了 bug 不知道在哪一层想换个模型、改个工具得先学框架的抽象面试被问讲讲你们的 Agent 架构只能背 API。所以我决定一件件自己写。下面按这个顺序拆。二、function calling不是 AI 的新能力是一份协议很多人觉得 function calling 是AI 学会了调函数。不是。它是一份协议约定你告诉模型有这些工具、参数长这样JSON schema模型回复我要调这个、参数是这些JSON你负责真的执行。模型从来没碰过你的函数是你的代码在派发。理解这一点工具注册就好写了——本质是把 Python 函数签名翻译成 JSON schema。我用一个装饰器自动完成tooldef query_order(order_id: str) - str:“”查询订单状态与物流。Args: order\_id: 订单号如 ORD20240001。 ...装饰器用inspect反射签名 pydantic 校验参数自动生成 OpenAI 的 schema。模型返回{order_id: ORD20240001}pydantic 校验不合法就回灌让它重试。整个 function calling 机制几十行就讲透了。它不是魔法是JSON schema 派发。三、ReAct所谓自主决策就是一个 while 循环ReActReason Act被讲得很玄。其实流程朴素得有点扫兴模型看问题 → 要调工具要执行工具把结果喂回去再问一次不要输出最终答案写成代码核心就是一个循环加一个停止条件for step in range(max_steps):resp llm.chat(conv.to_dicts(), toolstool_schemas)if not resp.tool_calls:return resp.content # 模型不再要工具 → 最终答案for tc in resp.tool_calls:result execute_tool(tc)conv.tool(result, tool_call_idtc.id, nametc.name) # 结果回灌但这里有个反直觉的点ReAct 的难点不在循环在防御。模型会卡死连续调同一个工具、会幻觉参数、会无视你的确认要求。真正花心思的是这些max_steps硬上限防死循环连续 3 次相同调用 → 判卡死强制停止工具执行报错不崩把错误回灌让模型换法子写操作取消订单、退款打requires_confirmation标记先问用户这些才是工程。框架替你做了所以你以为 ReAct 很简单。而且——这些不是 ad-hoc 补丁。先记住它们第六节会收回这条线它们其实是一种更普适思路的具体实现叫给不可靠的 LLM 套一层审视。四、多 Agent最容易过度设计的地方Multi-Agent最容易让人想多。我一开始想上 Actor 模型——每个 Agent 一个消息邮箱搞订阅、序列化、生命周期。写了两小时停下来想了想拓扑发现自己犯傻。我的系统是静态 DAG用户问题 → 路由识别意图 → 挑对应 Agent → 合并回复。这张图是固定的不需要 Actor 那套动态订阅。函数式 fan-out 两个函数就够def fanout(agents, msg):with ThreadPoolExecutor() as ex:return [f.result() for f in [ex.submit(a.run, msg) for a in agents]]def merge(results, llm):if len(results) 1:return results[0].content # 单 Agent零 LLMreturn llm.chat(…).content # 多 Agent一次摘要去重Actor 要 3 倍代码收益为零。这不是偷懒是拓扑分析后的工程判断——我把这个否决理由写进了设计文档因为为什么不用 X往往比用了 X更有信息量。真正用上多 Agent 的地方是路由支持多意图。用户说查下 ORD001顺便问退货政策——既是订单又是 FAQ。老项目if/elif只能选一个必然漏处理。这里返回多意图fan-out 并行两个 Agent再 merge。这才是 Multi-Agent 协作的真实形态不是一堆 Agent 互发消息是一次请求里的并行分工。五、实测function calling 比 prompt 强强多少光讲道理不算数。我跑了 40 个 prompt × 3 种让模型调工具的方式120 次真实调用方式总成功率FAQ 场景原生tools参数95%87%response_formatjson_object95%87%纯 prompt 引导“输出 TOOL: 名字”72%33%这张表回答了一个真问题function calling 到底比 prompt 强在哪、强多少强在可靠性。原生协议和 json_mode 打平95%因为它们都给了模型一个结构化的契约去遵守。纯 prompt 引导在 FAQ 场景只有 33%——模型压根不按你规定的格式随手回你一段自然语言。结论很直接function calling 不是花架子。能用原生协议就别用 prompt 硬模拟。剩下 5% 的失败更有意思——不是协议不稳是模型觉得自己知道答案跳过了检索工具直接回答。这是 RAG 的老难题得靠 prompt 强制检索解决跟换不换调用方式无关。六、LLM 只是跑出结果你还需要一层审视写到这停下来看一个贯穿始终、却很容易被Agent 很酷盖过去的事实实测里那 5% 的失败、72% 的 prompt fallback说的是同一件事——LLM 是概率性的。它会跳过你给的检索工具直接编、会不按你规定的格式输出、会对着一个不存在的订单号一本正经地胡说。跑出结果和结果可靠之间隔着不确定性。这是 LLM 和传统确定性开发的根本边界。你写if x 0:它永远只在 x0 时进分支你让 LLM 判断意图它有概率判错。你不能像信任 if/else 那样信任 LLM 的任何一次单点输出。所以一个能上生产的 Agent 系统光靠 LLM 不够外面必须套一层审视机制。两种形态on-the-loop——系统在回路上监督。不信任单次输出用确定性代码约束它max_steps防死循环、连续调用检测防卡死、JSON schema 校验防乱编参数、工具报错回灌让它重试、路由置信度低于阈值就降级为请您描述清楚一些。LLM 每走一步都被一道闸门拦一下。in-the-loop——人在回路里把关。高风险动作绝不自动执行取消订单、发起退款这些有现实后果的操作打requires_confirmation先回确认取消 ORD001 吗用户点头才放行。把人插进回路用人的确定性兜 LLM 的不确定性。这套把不可靠的 LLM 单元套进一层驾驭的思路有个名字Harness 架构——上下文管理 评估循环 护栏目的就一个让 AI 可靠地完成任务。Claude Code、Cursor 这些工程化做得好的 Agent内核都是 harness它们的好用很大程度来自 harness 做得厚不是模型本身多神。回头看第三节那些防御max_steps、循环检测、错误回灌、requires_confirmation——它们不是临时补丁正是 harness 的具体实现。on-the-loop 是max_steps和校验in-the-loop 是requires_confirmation。每写一层 LLM 调用你都会本能冒出一句它要是出错怎么办然后加一道审视。手写一遍这句话会问到你的肌肉记忆里。而且这些审视现在还是散落在各模块里的——agent.py 管循环、tools.py 管校验、system 管路由阈值。当它们被收敛成一个统一管上下文、评估循环和护栏的运行时层就是harness runtime。Claude Code、Cursor 好用的秘密LangChain 真正在卖的东西很大程度就是这一层——而这层该长什么样手写一遍你就知道了。这也是为什么Multi-Agent 到底比单 Agent 强在哪的答案不在 Agent 数量而在你愿意为不可靠性配多厚的审视层。七、写完之后手写一遍我得到了什么不是以后可以不用框架了。框架依然有价值——省事、有生态、有社区。而是用框架时终于知道每一行在干什么。agent.run()卡住我知道去查哪一层想加个工具我知道在哪注册面试被问架构我能讲清为什么这么设计。还有一条更重要的懂了 LLM 的边界在哪——哪些可以交给概率哪些必须用确定性兜底。这条边界不亲手写一遍看不见。会用和懂之间隔着一条手写的沟。框架帮你跳过了实现但没帮你跳过理解。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
