最近这几年，“智能体”这个词几乎被聊烂了，但真正能把架构思路讲明白的文章其实不多。Anthropic 发过一篇《Building Effective Agents》，我前前后后读了不少遍，每经历一个项目回头再看，感受都不一样。这篇笔记不算长，但信息密度很高，几乎每一段都能对应到实际开发中的痛点。如果你正准备做智能体，或者已经在 LangGraph、Coze、Dify 这类平台上折腾了一阵子，我强烈建议你先把这套底层逻辑梳理清楚，否则很容易陷入一种状态：工具用得很熟练，但方案总差一口气。

这篇文章就是我从那篇架构笔记出发，结合自己折腾过的项目踩坑经验，把它拆开揉碎讲清楚。我会从概念边界、设计模式、工程落地的角度展开，尽量用大白话，但该严谨的地方也不会含糊。

1. 先搞清楚一件事：工作流和智能体，根本不是一回事

1.1 一个判断标准：谁在控制流程

很多人把“调用了大模型接口”当成智能体的标志，这其实是个认知误区。Anthropic 那篇笔记里有一个很关键的区分：工作流（Workflow）和智能体（Agent）是两种不同的东西。

工作流的特征是“预定义代码路径”。也就是说，系统要做什么、步骤怎么编排、每步之后怎么流转，全部由开发者提前在代码里写死。大模型只是流程中的一颗螺丝钉，负责某个环节的生成、判断或转换。比如你写一个脚本：先让模型做关键词提取，然后把提取结果拼成搜索 query，再让模型根据搜索结果写摘要——这个流程从头到尾都是你设计的，模型没有决策权。

智能体的特征则是“模型动态控制流程”。系统只给定目标、可用工具和约束条件，接下来该调用哪个工具、按什么顺序调用、结果不满意要不要重试、什么时候算完成，这些都由模型在运行中自行决策。它的行为不是静态写死的，而是围绕目标动态展开的。

1.2 为什么这个区分如此重要

这个区分不是学术概念抠字眼，它直接决定你会不会过度设计。

我知道很多团队看到“智能体”这个概念就兴奋，什么场景都想上 Agent。但 Anthropic 在笔记里摆了一个很现实的数据和论点：工作流和智能体在大模型任务上都能带来效果提升，其中智能体的优势和潜力最大，但它对应的代价也最高——延迟更高、token 消耗更大、错误模式更复杂、调试排查更难。如果简单的工作流已经能解决，强行上 Agent 只会给自己找麻烦。

我见过最典型的一个失败案例：有个团队想做智能客服系统，一上来就上了多智能体框架，搞了三四个子 Agent 互相协调，结果上线第一天光是 Agent 间的死循环就把 token 费烧穿，客服问题的解决率反而没有原来那套简单的意图识别 + 规则引擎高。后来我帮他们梳理，真正需要模型自主决策的环节其实只占两成，其余完全可以用固定流程覆盖。

所以在你读后面的架构模式之前，先建立这样一个思维习惯：先搞清楚你的系统哪个环节最需要“灵活性”，然后只在那个环节引入智能体，其他部分能写死就写死。

1.3 落地场景直观对比

我常用一个例子来区分这两类场景：

• 工单自动分拣：用户提交一个工单，系统判断它属于哪个类型，再推到对应部门。这属于工作流，因为分拣的类型和路由目标是确定的，模型只需要做一次分类。
• 自动化代码修复：给 Agent 一个 Bug 报告，它需要自己读代码、定位问题、改代码、跑测试，发现测试失败还要接着修。这就是标准智能体场景，因为下一步怎么做完全依赖上一步的反馈。

判断的核心一句话：如果动作空间是你预先枚举好的、每一步的转移关系是确定的，那是工作流；如果模型需要根据当前状态自行选择动作、甚至自行规划动作序列，那是智能体。这两个的工程复杂度完全不同，预算和上线周期也完全不在一个量级。

2. 三条黄金法则：你的系统该用哪一层？

2.1 法则一：最简单方案优先

Anthropic 那篇笔记里有一句话我印象特别深：“智能体并不会随随便便就把一个问题解决得比大模型本身更好”。很多任务直接用大模型单次调用就能完成，根本不需要额外的框架包装。

我第一次做智能体项目时就吃过这个亏。当时想做一个“资料整理智能体”，需求是让用户丢一篇文章进来，自动输出一份结构化的笔记摘要。我第一反应是给它配上网页检索工具、知识库工具、甚至接了个播客转写工具，结果搞了整整两周，效果还是不稳定。后来我退回到最简单的方式：直接把文章内容丢给大模型，让它按模板输出摘要，效果反而干净利落，用户的满意度还更高。

这条法则是很多资深从业者反复强调的：能用一次 API 调用解决，就不要上工作流；能用工作流解决，就不要上 Agent；能用单个 Agent 解决，就不要上多 Agent。复杂度每上一层，你要面对的不可控因素就多一个数量级。

2.2 法则二：延迟上智能体，而不是抢先上

这里有一个很朴素的道理：智能体适合解决的是“问题空间大、最优路径不唯一”的场景。如果你的任务只有一两种标准解法，那模型直接输出结果就行，路径的灵活性反而是负担。

举个例子，写一篇营销文案，它可能适合用工作流：先提取产品卖点，再根据目标用户调整语气，再生成最终文案。但你不需要一个能自由调工具、自己选策略的 Agent。反过来，用自然语言操作一个复杂的视频剪辑软件，这就是典型的 Agent 场景，因为用户的需求可能是“把这里调得更有氛围一点”，具体怎么操作模型必须自己判断。

核心判断标准很简单：你有没有把“怎么做”的规则写清楚的能力？如果能写清楚，就去写工作流；如果实在写不清楚，或者规则组合空间太大，才轮到 Agent 出马，让它通过试错和反馈自己找到路径。

2.3 法则三：为智能体保留人工兜底和可观测性

这一点笔记里没有大篇幅展开，但我从项目里得到的教训非常深刻。

一旦决策权交给模型，你的系统就不可避免地会出现“计划外行为”。模型可能调用了一个你没预料到的工具，可能在某个分支上反复重试，可能明明已经拿到结果却因为“觉得不完美”一直不终止。这些行为在生产环境里是致命的。

所以当你决定引入智能体时，至少要同时做三件事：

• 设定最大迭代次数和超时时间，超出就强制中止并走降级逻辑；
• 保留完整的行为日志，包括每一步的思考过程、工具调用参数、返回结果；
• 在关键业务节点上留一个人工审核位，尤其是涉及资金、合规、对外发布的场景。

智能体适合处理的是“过程可以自主、结果需要可控”的任务。如果你的业务要求每个环节都完全确定，那它就不适合用智能体。

3. 五大工作流模式拆解：从提示链到评估者-优化者

Anthropic 的笔记把常见的编排方式归纳成了五种工作流模式。这五种模式并不复杂，但每一个都有自己的适用边界。我结合实际项目逐个讲清楚。

3.1 提示链（Prompt Chaining）：把大任务拆成顺序小节

提示链的核心思路是把一个复杂任务拆成多个顺序执行的步骤，上一步的输出作为下一步的输入，中间还可以插入必要的检查点。它的典型应用是内容生成：先写大纲，再逐节展开，最后统一润色；也可以用于批量处理：先做格式转换，再做字段提取，再翻译。

这种模式在什么时候特别有价值？就是我前面说的，当任务可以被分解成清晰的、有先后依赖关系的子任务，并且每一步的输出质量会显著影响后续步骤时。比如在做营销邮件的自动化生成时，如果一次调用让模型直接写完整封邮件，经常会出现前后风格不一致、逻辑跳脱的问题；但用提示链拆成三步——定主题、写正文、做标题优化——每一环节专注一件事，效果会稳定很多。

写提示链时最容易踩的坑有两个。第一个是每步之间缺少“把关”，你需要在步骤间嵌入一些轻量校验逻辑，比如长度检查、JSON 格式校验、关键字段存在性检查，不要盲目地把上一步的输出直接灌给下一步。第二个是把链条拉得太长，每增加一个环节就增加一次延迟和一次失败可能，理想的链条是 3 到 5 个环节以内。

3.2 路由（Routing）：让最合适的模型处理最合适的事

路由模式解决的是“输入类型高度分化、需要分类后再分别处理”的问题。它一般分两跳：先用一个分类器（可以是大模型，也可以是小模型甚至规则）判断输入类别，再把不同类别的输入分发到对应专门优化的提示词或模型调用上。

这个模式最有价值的点在于：你不需要用一个超大参数的模型解决所有问题，也不用为所有场景维护一套复杂的通用提示词。比如我做过一个文档处理工具，用户会输入各种内容：合同文本、技术博客、会议纪要、客服对话记录。如果所有内容都用同一套提示词处理，效果必然一般。后来用了路由：先分拣出内容类型，然后合同走严谨条款摘要模板，技术博客走要点提炼模板，客服记录走工单结构化模板。同样的模型能力，整体输出质量提升了一个档次。

路由方案实现不难，但它有一个关键前提：分类本身要足够可靠。如果分类错了，后面的所有环节都会跟着错。所以在做路由时，我会额外加一个置信度判断——分类结果把握不高时，走一个统一的默认处理分支，而不是强行塞进某个特定分支。

3.3 并行化（Parallelization）：拆成多个子任务同时跑

并行化模式适合抽丝剥茧式的任务：把一个任务拆成多个互不依赖的子任务，让模型并行处理，最后再汇总。Anthropic 笔记里把并行化分成两种子类型。

第一种是“分段式并行”，大块工作拆成小块独立完成。比如做行业调研报告时，可以把“市场现状”“竞品动态”“技术趋势”“用户痛点”几个板块并行生成，最后统一组装。这种方式能明显降低延迟，因为各个部分互不依赖，同时跑比串行快得多。

第二种是“投票式并行”，同一个任务交给多个模型实例分别做，再用投票或评分机制选出最优结果。这种方式适合那些“答案没有唯一标准、但质量可比较”的场景，比如代码审查、内容合规判断、创意方案筛选。多个角度同时审，能有效减少单一模型视角偏差带来的问题。

并行化的实现细节里，有一个技术要点：子任务的拆分粒度要均衡。如果你把一个任务拆成 A 子任务需要 10 秒，B 子任务需要 2 分钟，那并行化节省的时间其实很有限，因为整体耗时会卡在最慢的那个子任务上。合理的做法是先粗剖一遍，看每个子任务的预估复杂度是否接近，再决定要不要并行。

3.4 编排者-协调者模式（Orchestrator-Workers）：动态拆解复杂任务

编排者-协调者模式是五种工作流里最接近“弱化版智能体”的一种。主模型负责任务拆解、派发，并汇总各子模型的结果；子模型负责执行被分配的具体子任务。它和前三种模式的最大区别在于：任务拆分的方案不是预先设计的，而是由编排模型根据动态输入现场决定的。

这种模式非常适合那些“任务目标明确，但子任务的内容和数量不固定”的场景。Anthropic 笔记里举了一个很生动的例子：让智能体对某个行业做多维度资料搜索和整理。用户输入“我是一家 SaaS 公司的市场负责人，想了解教育行业的市场趋势”，Agent 会结合行业特征自行拆解出：客户群体分析、采购决策链、竞品格局、获客渠道、监管环境等子任务，然后分发给多个搜索 Worker 并汇总成报告。

我第一次尝试这种模式是在做一个“竞品分析自动生成器”时。之前用提示链，发现竞品数量不确定，每家公司的数据字段也不一样，提示链写死步骤根本覆盖不了。换成编排者-协调者之后，编排模型先列出当前竞品名单，再为每一个竞品生成一个独立的 Worker 分析任务，最后汇总成一章对比报告，效果立马就对了。

这里要注意的是，编排者模式对 token 的消耗相当大，因为它本身不产生太多最终内容，大部分 token 都消耗在“拆解-分派-汇总”的元操作上。如果你的任务结构相对固定，就别用这个模式；如果子任务确实动态变化，这个开销才值得。

3.5 评估者-优化者模式（Evaluator-Optimizer）：生成-反馈的迭代闭环

评估者-优化者模式适合那些“一次生成很难到位、需要反馈迭代”的场景。它的结构是：一个生成模型产出内容，一个评估模型对产出质量打分并给出修改建议，生成模型再根据建议进行优化，循环直到达到质量标准。

这个模式的灵感来源其实很像真实工作里的“初稿+评审”机制。我经常把它用在文案创作类任务上，尤其是那种用户只给了一句简短需求、但期望高质量长文案的场景。比如“写一封给客户的项目交付说明邮件”，生成模型先按基本要求写一版草稿，评估模型从语气、结构完整性、风险信息覆盖等维度打分，指出“缺少时间节点说明”“语气过于生硬”“结尾没有明确下一步”等问题，生成模型再改一版，效果通常会显著提升。

但我要提醒一点：评估者-优化者模式是有成本陷阱的。如果评估环节的标准设计得模棱两可，模型可能陷入无限循环，不断改，不断被评“还可以更好”，最终把 token 消耗到一个让人心疼的程度。所以实操时必须设定最大迭代轮数，并且在每轮评估时要求评估模型明确区分“必须修改”和“可选优化”两类建议，只在必须项未清零时才继续迭代。

这五种工作流模式是基础积木，实际项目往往是它们的组合。比如先路由分类型，再对其中一类走提示链，另一类走并行化；或者先用提示链输出初稿，再用评估者-优化者做打磨。模式本身没有高低之分，组合得当才是关键。

4. 真正的智能体：两种形态与工程上的借力点

4.1 自定义智能体：自由但费心

当你通过工作流已经把任务拆解到极限、仍然发现某些环节需要模型自主规划动作时，就需要上真正的智能体了。Anthropic 的笔记里把智能体分成了两种形态：自定义智能体和封装式智能体。

自定义智能体在工程实现上更为复杂。它本质上是一个自主循环系统：模型接收目标和环境反馈，决定调用什么工具，工具返回结果后再决策下一步，循环往复直到完成目标或触发终止条件。我最早实现这类循环是在做“自动修复前端代码风格问题”的工具上：接收一段不规范代码，自己调用 lint 工具、读错误日志、修改代码、再 lint，直到全绿。这个流程如果让我预先写死分支逻辑，几乎不可能覆盖所有错误类型，所以必须让模型自己决定下一步。

实现这种循环的核心工程要素是：一个清晰的工具接口、一个可靠的终止机制、以及一套完整的状态记录。工具接口要做成可枚举的 JSON Schema 形式，让模型每次决策都走“选择工具 + 填写参数”的模式，而不是文本生成式的乱写；终止机制要包含最大步数、无进展判定（连续 N 步操作没有改变状态就停止）、以及用户主动中断通道；状态记录则要把每一步的输入输出、模型思考过程、工具返回结果存下来，方便事后复盘和调试。

4.2 封装式智能体：更优雅的封装选择

封装式智能体是另一个重要选择。它的核心思路是基于一套框架协议（比如模型上下文协议 MCP，Model Context Protocol）进行标准化集成，让智能体框架能够统一发现、调用和管理各种外部工具和数据源。这个思路的价值在于：与其针对每家平台、每个工具单独写适配层，不如用一套标准协议把工具都“插”进去，相当于给智能体做了一个统一插线板。

这种封装式方案，其实就是目前市面上所谓“平台搭建的智能体”和“用 Python 自己搭的智能体”的一个关键区别。你用 Coze、Dify 这类低代码平台搭智能体，工具接入、上下文管理、日志追踪基本都是平台帮你封装好的，开箱即用，但你能控制的细粒度有限；你用 LangGraph、LlamaIndex 这类代码框架自己搭，上下文窗口策略、工具调用重试逻辑都能精细控制，但所有封装都要自己处理，工作量也成倍增加。

我自己的经验是：如果只是做一个内部使用的效率工具，低代码平台足够，省时省力；如果要做一个对外交付、需要深度定制和长期演进的系统，还是老老实实走代码框架加封装型协议这条路。判断的尺度是：你更缺时间成本还是更缺控制力。

4.3 工具设计：智能体的胜负手

Anthropic 的笔记里用了大量篇幅强调工具设计，但很多人在实操中完全不重视这个环节。工具设计的好坏，直接决定智能体的成败。

好的工具设计要满足三个原则：

• 命名要像 API 文档一样精准。比如工具名用search_sales_orders，不要用query_data这种含糊名称。因为大模型是靠工具名和描述来推断工具用途的，命名含糊，它就不会在关键时刻调对工具。
• 参数要带类型和枚举值说明。参数 schema 里尽量把可选值列清楚，比如订单状态字段注明["pending", "paid", "shipped", "cancelled"]，避免模型传一个领域里根本不存在的垃圾值。
• 描述要写“什么时候用”而不是“是什么”。比如股票价格查询工具，描述写“当用户询问某一公司的实时或历史股价时使用”，而不是“获取股票数据的函数”。前者是引导模型在正确场景下触发，后者只是一句没用的说明。

这个道理特别像工具类软件里的“空状态引导”。用户不知道这个功能什么时候该用，它就永远不会被用。模型也是一样。

4.4 上下文管理：别把什么垃圾都塞给模型

智能体运行过程中，最常犯的错误就是把每一步的结果全部堆进上下文，导致上下文越来越长，最后不仅 token 成本爆炸，模型还会被无关信息干扰，决策质量急剧下降。

Anthropic 的笔记里关于上下文管理给了一个很重要的指导思路：不能把完整对话记录一味塞给模型，而应该主动管理上下文中的内容。常用的处理策略有以下几种：

• 窗口化（Windowing）：只保留最近 N 轮的交互记录，更早的内容丢弃或摘要化。
• 结构化摘要（Summarization）：当轮次太多时，让模型对历史做阶段性摘要，摘要成为长期记忆的替代品。
• 关键信息提取（Extraction）：把历史中影响决策的关键数据结构化抽取出来，比如已经完成的任务清单、已经尝试过的失败方案、用户的偏好设定，之后每一轮都把结构化关键信息注入上下文替代原文。

我在做长任务智能体时，用的比较多的组合是窗口化 + 关键信息提取。会话早期，完整保留每轮上下文；当累计长度到达阈值后，触发一次压缩，把已明确完成的步骤汇总成一行记录，把用户偏好提取成结构化字段保存，然后清空旧上下文。这样既保留决策所需的记忆，又不会让对话记录无限膨胀。

4.5 记忆与多智能体：最近讨论度很高的扩展方向

顺着上下文管理，自然引出记忆这个话题。现在很多团队在做 Agent 时，都会问“能不能让智能体记住用户偏好”。记忆不是简单地保存对话历史，而是要区分短期工作记忆和长期语义记忆。短期记忆就是你正在处理的这条任务的上下文；长期记忆是跨会话的用户画像、历史决策、偏好习惯。

长期记忆的实现方案，业界目前比较常见的做法是把记忆转成向量存进向量数据库，在每轮对话开始时做语义检索，把最相关的几条记忆注入上下文。这个方案有效，但要注意隐私合规，尤其是涉及用户个人信息时，不能一句话都不说明就开始沉淀记忆。

多智能体是另一个热词。很多团队一聊架构就想着搞多个 Agent 协作，但 Anthropic 那篇笔记里的态度非常审慎：多智能体只在少数场景下才有收益，比如多个角色需要独立工具集和知识库、或者任务天然可并行时。最常见的安全做法是“单个智能体 + 工具集”的组合，而不是一上来就搞多智能体编排。多智能体系统的核心难点不是把 Agent 们串起来，而是让它们之间共享状态和避免冲突，这个复杂度是指数级上升的。如果你还没有把单个 Agent 吃透，我劝你先别碰多智能体。

5. 实战选型与常见问题：从需求到落地的避坑指南

5.1 如何从需求出发选择架构

我在带项目时，很少让团队直接进入编码或配置阶段，而会先帮助他们回答一个核心问题：你的系统到底需要哪种程度的自主性。

回答问题最简单的路径是画一条思考线：

• 这个任务的输入和输出是否能被严格定义？如果能，直接用单次大模型调用。
• 任务能否被拆分成固定的几步骤？如果能，且每一步之间是先后依赖关系，用提示链。
• 输入类型差异很大、不同类别的处理方式完全不同？用路由。
• 任务可以拆成相对独立、互不依赖的子任务？用并行化。
• 输出质量要求高、需要多次迭代打磨？用评估者-优化者。
• 子任务的内容和数量事先不确定、需要动态规划？用编排者-协调者或单智能体。
• 模型需要自主调用多个工具并根据反馈调整策略？用智能体。

这些选项之间不是越往后“越高级”，而是每一种都对应不同的工程成本和效果预期。你可以把它理解成汽车变速箱的档位：不是档位越高就越好，而是匹配你当前的路况才是最优的。

5.2 低代码平台和手写框架怎么选

前面提到了平台和代码框架的区别，我在这里把二者的对比表列出来，方便你直接参考：

对大多数团队，我的建议是先用低代码平台把业务逻辑验证跑通，不要迷信“自己写代码更专业”。这个过程帮助你理解这套系统的行为边界和效果预期；一旦验证了场景确实需要更精细的控制，再迁到代码框架上，此时你已经知道要控制什么了，迁移成本反而更低。我见过很多团队一上来就用代码框架写了个简陋的 Agent，结果调试了一周还在解决最基本的工具调用问题，这种弯路完全可以通过混合路径规避。

5.3 调试智能体的核心思路：关注工具调用轨迹而非最终结果

智能体和传统程序最大的调试差异在于：传统程序可以逐行打断点，看状态；智能体的行为选择是模型概率性的，你无法简单复现 Bug。所以调试智能体要换一种思路——重点看工具调用轨迹。

我在排查智能体问题时，一定会先拉出这类日志：模型每一轮的思考、选择的工具、填入的参数、工具返回的错误信息。通过这些日志判断失败属于哪一类：

• 模型选错了工具？大概率是工具命名和描述写得不对，去改工具文档。
• 模型生成了非法参数？大概率是参数 schema 约束不足，去补枚举值和格式正则。
• 工具本身报错？检查工具代码，不要把这笔账算到模型头上。
• 模型在同一个工具上反复调用但结果无变化？可能是工具返回信息不完整，或者模型没有理解返回结果，需要调整工具返回内容的格式和说明。
• 模型在应该结束时没有结束？检查终止条件是否明确，提示词里是否明确告知“完成目标后输出最终答案”。

这套排查思路和传统后端联调很像，只不过你要调试的对象从“固执的同事”变成了“一本正经地胡说八道的 AI 同事”。

5.4 企业落地中的典型失败模式和兜底策略

最后聊几句企业落地层面的经验。智能体在 demo 阶段通常很惊艳，一上生产就翻车，原因往往不是模型能力不够，而是工程兜底没做到位。我总结了几种最常见的失败模式：

第一是“可复现性缺失”。同样的输入，这周跑出 A 结果，下周跑出 B 结果，业务方不敢用。应对方案是固定模型版本、温度参数和随机种子，并保留每次运行的完整记录，至少在出问题时能复盘。第二个是“没有降级路径”。智能体一挂了，整条业务线就瘫了，这比传统系统更危险。必须设计降级方案：Agent 超时报错后走人工处理队列或规则引擎兜底。第三个是“评测缺失”。很多团队在未定义清晰的评估指标的情况下就直接上线 Agent 了。你需要准备一套评测集，里面包含正常样本和异常样本，每次更换提示词或模型版本后，先跑一遍评测集，对比通过率再决定是否上线。

第四个也是最重要的一条：不要在没定义“成功”之前就优化智能体。我看到太多团队日复一日调整提示词，试图让 Agent 在各种边缘场景下表现更好，却没有先想清楚一个最核心的问题——什么结果算完成，什么结果算失败，什么情况算成本失控？这三个定义不明白，优化就是在沙滩上盖楼。

5.5 面试视角：智能体架构的常见考点

结合搜索引擎里频繁出现的“智能体面试”这个热词，顺便聊一下这个话题。现在很多公司的 AI 岗位面试都会聊到智能体架构，面试官通常不会问“你会不会用 LangGraph”，而是会抛一个开放场景：“如果让你做一个自动客服系统，你会怎么设计，为什么？”

这时候学好 Anthropic 这篇架构笔记的价值就体现出来了。一个完整的回答应该包含：先分析任务是否真的需要智能体，还是工作流就能解决；如果涉及多类任务，考虑路由或者混合流程；在需要模型自主决策的地方，说明工具设计和上下文管理的思路；最后还要说明如何评测、如何兜底、如何观测。面试官想看到的是架构思维，不是某个框架的函数用法。当然，如果还能顺带讲一讲低代码平台和代码框架各自的优缺点，以及多智能体为什么大多数情况下不必要，那就更完整了。

这套思路也是我认为所有做智能体相关工作的开发者都应该练的基本功：不是为了给面试官背答案，而是因为想清楚这些问题，真的能在项目里少走很多弯路。

6. 我一直坚持的经验准则

写了这么多，最后分享几条我在实际项目中形成的习惯，希望对你有用。

我做智能体的第一个原则是“先画流程图，再写代码”。不管心里想得多清楚，动手之前一定把工作流用传统的流程图方式画出来，标清楚哪些环节用模型、哪些环节用规则、哪些环节要人工审核。画完之后，再对照这篇架构笔记里的模式看一遍：能不能用更简单的模式替代？这个习惯帮我避免过很多次过度设计。

第二个原则是“先保底，再优化”。所有自主决策类系统，我都先把退出条件、降级逻辑、最大成本限额这些安全机制写好，再开始调提示词和工具。没有兜底的智能体就像没有刹车的车，性能再好也不敢上路。

第三个原则是“把失败案例当成产品需求”。模型每一次出错的日志，我都不会只当作 Bug 修掉，而是归类存档，定期回看，看错误主要集中在哪类输入上。如果你的智能体总是在某类长尾场景上失败，与其继续调提示词，不如把它重新归类，单独加一个路由分支处理。模型不该解决所有问题，架构才是解决问题的核心手段。