过去一年我几乎把市面上叫得出名字的 Coding Agent 都试了一遍也花了不少时间在技术社区看各家团队分享实现细节。坦白讲早期我是抱着“让 AI 自动把 bug 修完”的功利心态去折腾的但真正让我印象深刻的不是某个模型能写多难的算法而是一套越来越清晰的分工大模型负责规划与推理工具链负责执行与落地。这个分工本质上就是我们今天讨论的 Agent “大脑—小脑”协同范式。Coding Agent 是这套范式最好的实验场一旦把里面沉淀出的控制循环、工具注册和反馈机制抽象出来你会发现它可以平移到财务、招聘、客服、运营这些看起来完全不搭界的行业。这篇文章把我踩过的坑、验证过的方法和最认可的实现方式都写下来希望能给正在从零搭建 Agent 的同学一条更少绕弯的路。如果你是第一次听说这个说法也别着急我会从最基础的认知开始讲。1. 为什么 Coding Agent 是最好的试验场1.1 反馈闭环让每一步都可验证编码是一个难得的“结果可以立刻校验”的场景。你写逻辑编译会告诉你有没有语法错误你改实现测试会告诉你功能是否正常你动依赖CI 也能帮你把回归问题暴露出来。每一环要么通过要么失败不会出现“你觉得自己做对了但没人验收”的状态。这个特性对 Agent 来说极其重要。因为 Agent 要持续工作必须不断拿到确定性反馈才能在错误发生后立刻调整策略。当我把“大脑—小脑”范式放进 Coding Agent 里验证时能完整做到可观测大模型输出一个决策小脑去调用终端、读写文件、执行测试执行结果再作为新信息回到上下文。整个过程像一本有目录的账本每一步都有迹可循。我曾经做过一个自动修单测的小实验最初以为核心难点是让大模型读懂堆栈后来发现真正花时间的环节是“失败日志 → 分析根因 → 修改代码 → 重新运行”这个循环的质量控制。这个循环跑顺畅了整个 Agent 的表现立刻就稳定了。更关键的是编码场景逼着你去回答一个哲学问题大模型到底应该决定什么如果让大模型直接输出整个文件生成动作很慢、token 消耗大而且你不会希望它随手决定依赖版本或者悄悄改变接口签名。但在“大脑—小脑”的框架里大模型只负责表达意图和步骤比如“第 12 行应该返回解析后的 JSON 而不是字符串”至于怎么修改文件、如何做语法检查那是工具链的职责。这个分工看起来简单背后却是完全不同的工程质量。1.2 编码场景逼你想清楚“什么该由大模型决定”现实中很多 Coding Agent 的评估差距根源就在这种分工上。同样是修一个 bug有些实现只是把上下文塞进 prompt 让模型直接输出补丁有些实现则是在一个可执行环境里反复跑测试、读覆盖率、看回归结果再自我修正。行业内像 Databricks 这类团队推出的 Coding Agent benchmark核心关注点已经偏向“真实任务完成率”而不是“单轮回答准确率”。这其实是在提醒所有人如果你的 Agent 连闭环评估都搭不起来那么它大概率只能处理“看起来像编程”的文本生成而没法真正解决工程问题。编码场景是“大脑—小脑”范式的练兵场因为这里既有足够复杂的推理需求又有足够成熟的工具链。Compiler、linter、test runner、git、package manager每一个都是现成的“小脑能力”。你不需要再为工具发愁只要把决策回路做好就能验证整个范式。而一旦这套范式在编码场景里跑通后面迁移到别的行业时唯一的难点就是如何为那个行业再造一套“小脑”。2. 大脑和小脑各自主导什么2.1 大脑规划、拆解与反思我理解的“大脑”不是指某一个单独的大模型而是承载在 LLM 之上的一组能力把大任务拆解成可执行的子任务基于当前状态和长期记忆决定下一步在失败之后进行反思并调整策略从工具返回的结果里提取关键信息。这里的关键词是“决定”。大脑做的事情是产生“决策增量”而不是完成一次完整的“成品生产”。拿做 PPT 的 Agent 来说大脑需要判断“用户提到的是产品发布会我应该先检索品牌色彩规范再生成内容大纲最后调用模板引擎渲染”而不是一次性把整份 PPT 的文字全部编好。它更像一个项目经理负责分派任务、检查交付、出现问题再返工。项目经理的价值不在于自己写文档而在于判断什么该做、什么时候做、做到什么程度算完成。所以我在实际设计里会尽量避免让大模型直接去做那些“一次成型”的操作。比如让大模型生成一份 200 页的报表即便它能生成也极易在中途出现幻觉和格式错乱。正确做法是大模型先决定“我需要哪几张表、每个表的数据来源是什么、校验规则是什么”再让确定性工具去生成和计算。2.2 小脑工具、技能与确定性执行“小脑”我理解成一系列确定性的能力模块文件读写、终端命令、API 调用、浏览器控制、数据库查询、OCR、文档解析、模板渲染。每一个都由真正的代码写成输入输出有严格 schema。大脑把决策转化为对某个工具的调用或一个调用序列小脑负责把这次调用变成真实世界的效果。“小脑”不只是函数封装层它可以复杂到内置完整的领域逻辑。比如财务对账 Agent 的“小脑”里不需要一个会推理的大模型只需要一个能对账单做归一化、按规则匹配、生成差异报告的确定性模块。这部分工作往往占整个 Agent 开发的大头。我经常跟朋友说与其在提示词里反复跟幻觉搏斗不如花精力把工具写扎实让“宁可不会做也不能瞎做”成为系统底线。一个“技能”Skill本质上是小脑里的一组可复用能力包包含工具定义、执行逻辑、可能的校验规则和示例。比如“读取 Excel 并做列映射”可以是一个技能“把 Markdown 转成 PDF”也可以是一个技能。Agent 则是指挥多个技能协作的决策者。Skill 是楼梯Agent 是拿着钥匙上楼的人这两层不能混为一谈。2.3 为什么“大脑”不能兼任“小脑”尝试让大模型自己完成执行会带来三个明显问题。第一输出延迟和 token 成本会指数级上升一个几十行的配置文件用代码改只要一秒用大模型生成可能就要几万 token第二大模型输出天然带有随机性你让它稳定地修改 20 处配置总有概率漏掉一处而这种遗漏在运行期才会暴露第三很多强规则任务比如格式转换、字段映射、数据清洗用代码实现是稳定且低成本的用提示词实现则会变成一个不断试错的无底洞。用人体类比会更直观大脑不会去指挥每一块肌肉纤维它只发出“我要拿水杯”这样一层意图小脑负责协调手臂肌群完成抓取并在中途自动做细微修正。如果大脑要接管每一条肌肉的收缩任何一个动作都会变得迟钝且容易出错。Agent 也是如此只有把执行下沉给确定性工具大模型才能把精力聚焦在真正需要推理的决策上整体稳定性才会有质的提升。3. 从 Coding 到千行百业同一个控制回路3.1 核心抽象控制循环、工具注册、记忆与反馈你拆开任何一个行业 Agent看到的骨架几乎都是同一套东西。首先是控制循环。Agent 在一个循环里反复执行“决策 → 执行 → 观察 → 再决策”直到任务完成或达到上限。这是区别于普通 LLM API 调用的核心特征。其次是工具注册表也就是所有“小脑能力”对大脑开放的统一接口包含工具名称、功能描述、入参和出参 schema。大模型只会看到这些接口不会看到工具背后繁琐的实现。第三是记忆系统短期调用记录加上长期事实库让 Agent 在多轮任务中不丢失上下文。最后是反馈和安全阀执行失败要能把错误信息完整传回大脑循环要有步数上限中断之后要能恢复现场。在 Coding Agent 里反馈信号来自编译器和测试用例在业务 Agent 里反馈信号可能是“外部 API 是否返回 200”“字段评分卡是否通过”“风控规则是否命中”。形式不同本质完全一致。因此编码场景沉淀出的这套回路几乎可以原封不动地移植到其他行业。3.2 三个跨行业案例的拆解说说我做过或调研过的三个方向它们看起来完全不沾边但内部结构高度相似。招聘初筛 Agent大脑负责读取职位描述和候选人简历抽取评价维度生成深度面试问题“小脑”则负责解析 PDF 和 Word、剥离敏感信息、按评分卡规则计算匹配分、更新 ATS 系统。这里人工总结出的业务规则全部落在小脑工具里大模型只做语义理解和观点生成。客服工单 Agent大脑把客户消息转成意图和路由决策判断该走退款流程还是技术支持流程“小脑”负责查询订单、调取退换货策略、执行开单动作、必要时升级给人工。财务核算 Agent大脑理解用户要出具什么报表设置核对维度和口径“小脑”解析流水文件、执行对账、按规则生成分类账和差异表。一切需要精确计算的步骤都不会让大模型碰。这三个案例的共同点是大模型不承担大量重复计算不承担精确文本格式转换不承担对海量记录的遍历。所有传统业务规则的沉淀最后都变成了一个“行业小脑”库这才是 Agent 在行业里能稳定运行的根本原因。3.3 最小可用 Agent 架构长什么样很多人一上来就问应该选哪个编排框架我的回答通常会让他们意外最小可用架构根本不需要框架。一个函数循环、一个工具集合、一块记忆已经能覆盖大量业务需求。真正的 Agent 核心是“决策循环”而不是某个库的名字。你可以用一个长度很短的主循环做大脑调度再用 Python 包一层工具注册剩下的事情交给反馈判断。当任务复杂度上升比如需要并行分支、状态机回退、人工介入审批再引入 LangGraph、CrewAI 这类框架也不迟。但你要知道框架帮你解决的是状态管理、工具调度和日志追踪这类“编排届”的事它不会替你做小脑工具。如果你只需要单轮任务或者在给定 prompt 后直接等结果那根本不需要 Agent直接用 LLM API 就行。先想清楚自己是不是真的需要循环是避免过度工程化的第一道门。4. 实操搭建一个带“大脑—小脑”结构的 Agent4.1 一个可运行的 Agent 循环原型我用一个最精简的例子说明这套范式如何落地。下面的代码看着很短但它包含了所有生产级 Coding Agent 的基础回路。def run_agent(goal, tools, max_steps12): memory [] state {goal: goal, completed: False} for _ in range(max_steps): # 大脑基于状态、记忆和工具定义决定下一步动作 decision llm_think(state, memory, tools.schema()) if decision.finish: # 大模型判断任务已完成 return decision.answer # 小脑用确定性代码执行真实动作 result tools.execute(decision.action) # 反馈把执行结果压缩成摘要写入状态和记忆 observation summarize(result) state.update(observation) memory.append((decision.action, observation)) raise MaxStepsReached(f任务未在 {max_steps} 步内完成)这里的 llm_think 实际应该输出一个结构化的动作意图通常是一个函数名加参数 JSONtools.execute 会按照这个参数去执行真实工具。注意那个 summarize执行结果可能很长如果直接把原始日志全部塞回上下文几轮之后上下文就会被撑爆。我们需要把结果压缩成摘要比如“测试失败的用例有 2 个错误集中在 session 模块”再放回上下文。这一步看似简单却决定了 Agent 能不能撑过超过 10 轮的任务。从这个原型出发你可以继续加长期记忆、人工确认、错误重试但骨架不会变。先让这条循环跑通再考虑炫技。4.2 小脑工具设计的三个原则我在搭建过多个 Agent 后总结出小脑工具设计的三个核心原则按重要程度排序。第一输入输出全结构化。工具能返回 JSON就不要返回自然语言段落。因为大模型的决策稳定性高度依赖它能否从返回值里精确读取字段一份干净的结构化结果比任何提示词都更能提升后续决策质量。第二每个工具必须原子化且尽量幂等。重复执行同一个操作不能产生严重副作用这样即使大脑判断失误工具层也能扛住。像“写入文件”这种工具最好带上版本标识或者执行前后 diff让系统知道发生了什么变化。第三工具必须有完整清晰的错误信息。要告诉大模型错在哪个环节、当前状态是什么、有没有推荐降级方案。大模型面对模糊报错时很容易陷入编造成功结果的循环。我见过最典型的失败案例就是工具返回了一串深层堆栈大模型不仅没看懂还反过来给了一段完全不相关的代码。这三个原则表面上是工程规范本质上是在给“小脑”划边界。边界越清晰大脑越不会越界。4.3 harness、框架与 Agent 的边界先想清楚谁在编排关于工具选型我经常被问到“harness 和 agent 到底什么区别”。我的理解是harness 是那个“控制场域”的壳子它负责管理循环生命周期、上下文窗口、工具交互协议和日志追踪Agent 则是壳子里真正做决策的那个“思考者”。框架和 harness 是基础设施而 Agent 的灵魂在决策逻辑和工具质量。实际项目中我推荐用成熟的 harness 管理状态机和工具注册因为自己从头写一套健壮的任务编排、重试和监控系统非常耗时。但与此同时千万不要指望框架替你完成“小脑”。框架可以帮你把工具调用流程理清楚但要工具本身足够可靠那仍然是你自己的工程问题。很多团队拿着 LangGraph 建了复杂的图结构却忽略了每个节点的工具质量最后整条链路依然脆弱。还有一点值得提醒Skill 是能力模块Agent 是指挥 Skill 的角色。让 Skill 复用、让 Agent 决策这两层职责要分清楚。好的工程实践是先把 Skill 单独开发和测试再通过工具注册表接入 Agent这样每个模块都能独立升级不至于一动全局崩。5. 常见问题与排查技巧实录5.1 症状与解法速查表我把自己实际遇到过的高频问题整理成一张表你可以直接对照排查。典型症状排查思路处理建议Agent 反复执行同一个工具既不继续也不退出上下文溢出或工具返回结果缺少状态标志给所有工具返回字段加上status和next_actions限制最大迭代步数工具报错后大模型仍然编造一个成功结果错误信息不够明确或返回值被当作普通文本错误必须包含stderr、退出码、失败环节明确提示“此次调用失败”上下文被日志塞满后续决策明显退化没有对执行结果做摘要压缩对长结果做summarize历史细节写入外部记忆只把摘要放回上下文Agent 一遇到多步任务就断片短期记忆和上下文窗口不足增加结构化记忆模块按主题保存关键事实某个工具调用的耗时过长循环阻塞工具缺少超时控制在 harness 层设置单次工具调用超时超时后重试或切换备选方案Agent 在关键步骤上反复征求人工确认把交互动作错误地塞进了主循环把人工确认拆成独立的待办队列不阻塞主流程同时给没有响应的人工确认设置默认策略这张表里的每一条都是我实际踩过坑之后总结出来的。其中“大模型编造成功结果”是最隐蔽也最危险的因为从日志表面看流程好像走完了实际上啥也没做。要根治它除了工具返回明确的失败标志还需要在 harness 里对工具执行结果做一层断言比如“如果工具状态是 failed则本轮决策必须针对失败做修正不允许直接进入完成态”。5.2 我踩过的坑从“改提示词”到“修小脑”项目初期我踩过一个特别典型的坑Agent 生成的报表总在某个边界条件下出错我第一反应是去改 prompt试图让大模型“更仔细”。但反复调试两周后问题依然存在。后来我把那部分逻辑抽出来看了一眼发现根因不在大模型而是负责计算的工具在空值处理时出了问题。那一刻我醒悟了一个道理很多时候 Agent 表现不好不是“大脑不够聪明”而是“小脑不够健全”。从那以后我遇到 Agent 表现不稳定第一件事不是调 prompt而是先审查对应环节的工具代码。如果工具本身有边界 bug你让大模型再聪明也没用反过来工具足够健壮时大模型只需要做简单的决策就能得到正确结果。这个排查顺序帮我节省了无数个小时。另一个常见问题是工具 schema 写得太含糊导致大模型即使判断出“应该用某工具”也不知道该传哪些参数。我的改进方式是为每个工具写一两个典型示例并在工具描述里说明常见误用。这一步其实很像给新同事写交接文档花不了多少时间但对智能体的稳定性提升非常明显。6. 给迁移到行业场景的三个建议6.1 先固化 20% 的确定性流程很多团队做行业 Agent 时上来就希望大模型处理所有模糊环节。但我建议反过来先找业务流程里确定性最强的 20%把它们做成工具和技能。比如合规审核里的字段必填校验、财务对账里的科目映射、客服流程里的订单状态判断这些都是规则明确、重复出现、代码可以轻松保证质量的部分。这一层“行业小脑”做扎实了大模型才能有余力去处理真正模糊的语义理解和复杂判断。6.2 建立自己的小 benchmark在你把 Agent 接入真实业务前先建一个只属于你这个场景的评估集。选 20 到 50 个有代表性的任务每天跑一遍记录完成率、失败原因和平均步数。这个基准不需要复杂关键是固定下来。有了它你才能判断一次改动到底是变好了还是变坏了。没有基准的 Agent 项目本质上是在裸奔。6.3 从单 Agent 到多 Agent不要太激进我看到很多团队刚做完一个单 Agent 原型就急着上多 Agent 协作最后被任务分配和消息同步折腾得半死。我的经验是先让一个 Agent 把“大脑—小脑”回路跑熟跑出稳定准确的业务结果再考虑是否需要多角色分工。多 Agent 不是银弹它只是把复杂任务切成多个决策头的工程手段如果每个单 Agent 本身都不够稳定多 Agent 只会把错误放大。从 Coding Agent 到千行百业这个历程最打动我的不是某个模型的能力飞跃而是一个朴素而扎实的工程抽象。凡是 Agent 表现稳定的模块几乎都把大量重活压在了小脑工具里凡是表现飘忽的模块几乎都是大家还在提示词里跟幻觉搏斗。我个人在实际打磨过几套行业原型后最大的体会是别急着让大模型更聪明先把它脚下的工具垫稳。只有“小脑”足够可靠“大脑”才有资格谈创造。
