Agent架构全景解析感知层、决策层、行动层、反馈层的原理拆解与工程实现同一个模型从3.8%到49%的SWE-bench通过率差距不在模型本身在架构结构。本文深度拆解LLM Agent的四层闭环架构从CoALA认知框架到ReAct/Reflexion/LATS三代执行循环从ACI接口设计到前缀缓存工程实践提供一套完整的Agent系统设计方法论。引言Agent不是ChatBot加工具2024年Princeton团队做了一个实验把GPT-4接入SWE-bench一个真实的GitHub Issue修复基准模型没换训练数据没动只改了一件事——接入模型的那套接口重新设计了一遍。通过率从3.8%跳到了12.5%。同年Anthropic把Claude 3.5 Sonnet接入一套精简框架两个工具Bash Edit加一条约束强制绝对路径。SWE-bench Verified得分49%。同一个模型从3.8%到49%。差距不在模型在结构。Agent不是聊天机器人加了几个工具。它是一个控制系统。核心问题不是怎么生成更好的回答而是怎么在开放环境中持续完成目标。控制系统有一个经典结构传感器采集信息 → 控制器做出决策 → 执行器改变环境 → 反馈回路检验效果。这个结构在工业控制、机器人、自动驾驶中反复出现因为它是任何需要在不确定环境中持续运行的系统的最小完备架构。LLM Agent也收敛到了同样的结构感知 → 决策 → 行动 → 反馈 → 感知 → ...这篇文章拆解这四层每一层在做什么为什么这么设计工程上怎么落地。第一部分全局框架 —— CoALA与四层闭环[外链图片转存中…(img-129UaB3n-1782457315815)]CoALA给Agent一个形式化的骨架2023年CoALACognitive Architectures for Language Agents试图回答一个问题所有LLM Agent的共同结构是什么答案是三个组件1. 记忆Memory分为工作记忆和长期记忆。长期记忆又分三种记忆类型含义工程对应程序性记忆怎么做事技能、流程工具定义、技能库语义记忆知道什么事实、知识库RAG、向量数据库情节性记忆经历过什么过去的成功和失败对话历史、反思记录2. 动作空间Action SpaceAgent能做的所有事情分为内部动作推理、检索、写入记忆外部动作调用工具、与环境交互3. 决策过程Decision Process从动作空间中选择下一步的机制。三者组合起来构成一个完整的认知架构。任何Agent系统不管它用什么框架、什么模型都可以用这套词汇来描述和分析。四层映射CoALA的形式化与控制论的四层闭环之间存在清晰的对应层CoALA对应核心问题工程关注点感知工作记忆的输入模型能看见什么观察格式、记忆检索、上下文管理决策决策过程下一步做什么推理链、规划策略、搜索算法行动外部动作空间对环境做什么工具定义、执行沙箱、权限控制反馈观察→记忆更新做对了没结果验证、反思机制、错误恢复四层各有独立的工程问题也有跨层的耦合关系后面逐层展开最后再讲耦合。Workflow vs Agent什么时候用哪个Anthropic在工程指南中做了一个关键区分Workflow编排型LLM和工具通过预定义的代码路径编排步骤确定开发者写死了流程适合定义清晰的任务。Agent自主型LLM动态决定自己的执行路径和工具使用步骤不可预测模型自己选择下一步适合开放式问题。选择原则从最简单的方案开始。Workflow提供可预测性和一致性Agent提供灵活性但代价是更高的成本、更难调试、错误会复利累积。只在复杂度确实需要时才升级到Agent。五种Workflow模式复杂度递增模式说明适用场景Prompt Chaining顺序执行每步的输出是下一步的输入流水线式处理Routing根据输入类型分发到不同处理路径分类处理Parallelization拆成独立子任务并行处理可并行任务Orchestrator-Workers中心LLM动态拆任务、分配、合并复杂多步骤任务Evaluator-Optimizer一个生成一个评估迭代改进需要质量打磨的任务大多数生产系统用Workflow就够了能解决的问题就不要上Agent。第二部分感知层 —— 模型能看见什么[外链图片转存中…(img-lmtNxn74-1782457315816)]核心矛盾上下文窗口有限而环境信息无限。模型不能直接看见环境它看见的是喂给它的文本。感知层的设计决定了模型能理解什么、会忽略什么、在哪里犯错。观察格式设计Agent-Computer InterfaceSWE-agent的实验揭示了一个反直觉的事实同一个模型仅仅改变它与环境交互的接口格式性能就能翻倍。这个发现催生了一个概念ACIAgent-Computer Interface。就像HCI为人类设计界面ACI为LLM设计界面。两者的需求完全不同维度HCI人类界面ACIAgent界面输入方式视觉、空间、交互文本、顺序限制因素认知负荷、操作习惯上下文窗口大小设计目标易用性、美观性信息密度、格式规范性三条设计原则1. 最小认知开销用模型在训练数据中自然见过的格式Markdown表格比自定义XML好带行号的代码比纯代码好结构化错误信息比raw stack trace好2. 先给上下文再要求精确输出不要上来就问第47行应该改成什么——先展示第40-55行的代码再问。模型需要足够的token看清楚才能给出精确答案。3. 防错设计强制绝对路径消灭相对路径错误用枚举参数替代自由文本在工具定义里写清楚不要做XAnthropic在SWE-bench开发中发现花在工具接口设计上的时间比花在prompt上的时间更有价值。一个具体的例子是文件浏览给模型看整个2000行文件它会迷失在中间给它一个分页查看器每次100行带行号带当前位置标记它能准确定位问题。这就是ACI设计的差距。记忆架构三层模型Lilian Weng在综述中提出了Agent记忆的三层模型对应人类认知科学中的记忆分类感知记忆Sensory Memory原始输入的第一层处理。对Agent来说就是API返回的raw JSON、终端输出的原始文本、截图的像素数据。持续时间极短很快要么进入短期记忆要么被丢弃。短期记忆Short-term / Working Memory也就是上下文窗口快但有限。128K token看起来很多但对一个需要跨越几十个文件、几百次工具调用的长任务来说很快就不够了。长期记忆Long-term Memory外部存储包括向量数据库、文件系统、结构化数据库。容量无限但检索有延迟且检索质量不稳定。工程实现上每层对应不同的技术方案层实现特点感知记忆工具输出格式化ACI设计管这里短期记忆上下文窗口管理压缩、裁剪、摘要长期记忆RAG / 文件系统 / KV Store需要检索策略Agent Patterns Atlas提供了几个记忆相关的工程模式Filesystem as Context把工作状态写入文件每次读取最新版本。文件系统本身就是一种外部记忆。Voyager的技能库就是这个模式——成功的代码写入文件按描述索引下次检索复用。Variables Manager显式追踪关键状态变量当前目标、已完成步骤、待验证假设而不是让模型从整个对话历史中隐式推断。RAG语义检索适合知识库查询但对状态追踪不太适用。上下文管理对抗信息腐化[外链图片转存中…(img-x9BGjf3z-1782457315817)]上下文窗口有一个不直觉的性质不是越长越好。Stanford的Lost in the Middle研究发现当关键信息落在长上下文的中间位置时模型检索性能下降30%以上。即使窗口足够大模型的注意力分布也不均匀——开头和结尾的信息更容易被注意到。更严重的问题是上下文超过窗口容量约40%后性能开始急剧下降不是线性衰减是断崖式。Agent在长任务中跑着跑着就不对了很多时候不是推理能力退化而是上下文已经腐化——充满了过时的工具输出、无关的中间步骤、早期的错误假设。五种生产级上下文管理策略策略原理效果压缩把历史对话摘要化保留关键决策和未解决问题ACON研究token减少26-54%准确率保持95%以上观察遮蔽隐藏旧的工具输出内容但保留工具调用记录可见JetBrains Junie实践JIT检索不预加载整个代码库需要看文件时按需拉取Claude Code95%的上下文节省来自按需加载工具输出卸载大输出写入文件系统上下文只保留摘要和路径减少上下文噪音注意力工程最关键信息放在prompt开头和结尾利用注意力分布特性ACON研究的一个重要发现优先保留推理链Thought而非原始工具输出Observationtoken减少26-54%准确率保持95%以上。这说明Agent的思考过程比观察结果更有保留价值。第三部分决策层 —— 模型怎么选择下一步[外链图片转存中…(img-H9TZaWWT-1782457315817)]核心矛盾搜索空间指数爆炸而计算预算有限。每一步决策模型面对的是一个巨大的动作空间调用哪个工具、传什么参数、还是先推理一下、还是回头检查之前的假设。决策层的设计决定了Agent在这个空间里怎么搜索、搜索多深、什么时候停下来。执行循环的三代演化Agent的决策机制经历了三代演化每代增加了计算成本也抬高了能力上限。第一代ReAct2023ReAct确立了至今所有Agent的基础循环Thought → Action → Observation。Thought: 我需要找到这个函数的定义 Action: Search[def calculate_total] Observation: Found in src/billing.py, line 47-62 Thought: 看到了问题在第53行的类型转换 Action: Edit[src/billing.py, line 53, ...] Observation: File updated successfully推理和行动必须交替进行纯推理Chain-of-Thought会产生幻觉模型编造不存在的事实纯行动无Thought直接调用工具会盲目执行模型不知道为什么要做这一步ReAct通过显式的Thought步骤迫使模型先说清楚我为什么做这一步再通过Observation用真实的环境反馈纠正推理。HotpotQA上的幻觉率从56%降到接近0%。但ReAct有一个局限它是单线的每一步做完就往前走不回头。如果某一步走错了后面所有步骤都建立在错误的基础上。第二代Reflexion2023Reflexion在ReAct的基础上加了一层如果任务失败了不是简单重试而是先反思为什么失败了把反思结果写入记忆下次避免同样的错误。Trial 1: 尝试 → 失败测试不通过 ↓ 反思: 我没有考虑到空数组的边界情况 ↓ 存入 episodic memory ↓ Trial 2: 读取反思 → 调整方案 → 尝试 → 成功这是一种语言强化学习——不需要更新模型权重用自然语言作为学习的介质。HumanEval代码生成的pass1从67%提升到91%。但Reflexion也有局限它只能在失败后学习。对于需要在行动前就深度规划的问题比如博弈、优化它仍然是被动的。第三代LATS2024LATSLanguage Agent Tree Search把蒙特卡洛树搜索MCTS引入Agent决策。不再是单线执行而是构建一棵搜索树Root: 当前状态 ├── Action A (评估分: 0.7) │ ├── Action A1 (0.9) ← 最佳路径 │ └── Action A2 (0.3) ← 被剪枝 ├── Action B (0.4) ← 低分不展开 └── Action C (0.6) └── ...LLM承担三个角色生成候选动作树的展开评估状态好坏价值函数失败时生成反思指导未来搜索方向HumanEval达到92.7% pass1。但代价是巨大的——每一步决策需要多次LLM调用生成评估可能的反思成本是ReAct的5-10倍。三代对比代方法循环结构计算代价适用场景1ReActThink → Act → Observe低1次调用/步常规任务2Reflexion执行 → 失败 → 反思 → 重试中失败时额外调用需从错误中学习3LATS多路搜索 评估 回溯高多次调用/步高价值复杂决策任务分解把大问题变成小问题一个复杂任务“修复这个bug”如果不拆分模型要在一个巨大的搜索空间中找到完整路径。拆分后“1. 定位错误 2. 理解原因 3. 写修复 4. 写测试 5. 验证”每一步的搜索空间大幅缩小。几种分解策略策略原理适用场景Orchestrator-Workers中心LLM拆任务和分配worker执行中心合并子任务相对独立极端分解每一步只做一件最小的、可验证的事错误不能累积的场景自动课程Agent自己生成下一个目标开放探索场景Routing根据输入类型分流到不同专用路径分类处理场景规划的工程权衡过度规划是一个常见错误。模型花了10步生成了一个完美的计划然后第2步的执行结果就偏离了计划的假设后面8步全部作废。Anthropic的工程原则直接从最简单的方案开始。实际的选择逻辑任务步骤固定→ 用Prompt Chaining确定性流程步骤不固定但可收敛→ 用ReAct单步循环随时调整子任务明确可独立→ 用Orchestrator-Workers分治高价值且可回溯→ 用LATS搜索树完全开放式→ 用自动课程让Agent自己定义目标一条经验规则如果Agent花了30%以上的token在规划上而不是执行上规划粒度可能太细了降低粒度让执行层的反馈来指导后续方向。第四部分行动层 —— 模型能对环境做什么[外链图片转存中…(img-6oYMUzJT-1782457315817)]核心矛盾工具越多能力越强但误选率也越高。行动层定义了Agent的手——它能触达什么、改变什么。工具设计的好坏直接影响Agent能否把正确的决策转化为正确的执行。工具设计原则Anthropic在SWE-bench开发中积累了一条核心经验花在工具设计上的时间应该超过花在prompt上的时间。五条设计原则原则说明示例格式自然用模型训练数据中高频出现的格式Markdown比自定义DSL好JSON比YAML好文档完整工具描述是给模型看的不是给人看的一句话说清用途、参数类型和约束、1-2个示例防错设计消灭歧义和自由文本强制绝对路径、参数用枚举、必填可选明确区分输出可读工具返回值是Agent的感知输入结构化、摘要化、只返回Agent需要的信息边界清晰每个工具做一件事工具之间不重叠避免什么时候用search什么时候用grep的模糊可用工具超过30个时模型的工具选择准确率开始明显下滑。改用动态加载每步只暴露Top 5-10个最相关的工具准确率提升约30%。动态工具管理在一个复杂的Agent系统中可能有几十个甚至上百个工具。全部塞进prompt上下文爆炸全部隐藏Agent不知道自己能做什么。几种平衡策略策略说明适用场景静态全量暴露所有工具schema始终在prompt里工具数 10动态加载根据当前任务阶段只暴露相关工具子集工具数较多阶段明确Skill DiscoveryAgent运行时自行查询可用工具注册表工具集合动态变化如MCP服务器技能库Agent创造新工具并自动入库最激进需要严格沙箱Vercel在v0中删掉了80%的工具反而得到了更好的结果。这说明工具数量不是越多越好精准比全面更重要。行动的安全边界Agent能做的事越多出错的后果就越严重行动层必须有安全机制。安全机制说明实现方式沙箱执行限制Agent的触达范围文件操作限制目录、网络请求白名单、代码执行容器化权限最小化只暴露完成任务所需的最小工具集不需要删除文件的任务就不暴露删除工具不可逆操作确认删除、发布、支付等操作需人类确认结构性要求不是信任问题Handoff机制超出能力范围时转移控制权携带完整对话历史确保上下文不丢失代码即行动Voyager引入了一种不同于JSON工具调用的行动方式直接生成可执行代码。传统方式{tool:move_to,args:{x:100,y:64,z:200}}{tool:mine_block,args:{block_type:diamond_ore}}Voyager方式asyncfunctionmineDiamonds(bot){awaitbot.navigate(100,64,200);constblockbot.findBlock(diamond_ore,5);if(block)awaitbot.dig(block);}代码的优势组合性复杂行为由简单函数组合不需要为每种组合定义新工具可验证代码可以运行、可以测试、可以type check可存储成功的代码直接入库变成新的技能代价是需要更严格的沙箱。JSON工具调用的安全边界很清晰参数验证就够了代码执行的安全边界需要容器级别的隔离。第五部分反馈层 —— 模型怎么知道做对了[外链图片转存中…(img-UfhXcKIh-1782457315817)]核心矛盾即时反馈便宜但浅层深层反馈有价值但贵。没有反馈的Agent是一个开环系统它不知道自己的行动产生了什么效果只能盲目前进错误会累积一步错步步错。反馈层闭合了这个环路让Agent能够感知行动的结果并据此调整。反馈信号的层次不同类型的反馈在延迟、成本和可靠性上差异巨大类型来源延迟可靠性成本执行反馈编译器、测试、API返回码即时高确定性低环境反馈状态变化观察秒级中低评估反馈另一个LLM评判秒级中有偏差中反思反馈模型自我审视秒级低可能过度纠正中人类反馈用户确认/纠正分钟~小时高高工程原则能用确定性验证就不用LLM判断能用LLM判断就不打扰人类。验证机制Anthropic推荐三类验证方式验证方式适用场景可靠性规则验证测试通过、类型检查、Linter最高确定性、无偏差、成本几乎为零视觉验证UI任务Playwright截图判断中适合无法用代码断言的视觉结果语义验证开放式任务LLM-as-Judge中有偏差建议用不同模型或promptClaude Code的实践验证了这一点给模型一种验证自己工作的方式哪怕只是运行测试质量提升2-3倍。Evaluator-Optimizer模式把验证做成迭代循环。一个LLM生成结果另一个LLM评估并给出改进建议然后第一个根据建议修改适合翻译、写作等需要打磨的任务。自我反思强大但危险Reflexion证明了自我反思的价值——Agent在失败后生成文本反思存入记忆下次避免同样的错误。HumanEval从67%到91%。但反思有一个被低估的风险过度自我纠正。研究发现当模型被指示再检查一下你的答案时在58%的情况下它会把原本正确的答案改成错误的。这不是bug而是反思机制的结构性问题——模型倾向于找到问题来证明反思是有意义的即使实际上没有问题。工程实践中的约束限制反思次数最多2-3次无限反思不会收敛只会震荡区分信心低和确认出错信心低但无外部证据表明出错就不反思只有外部反馈明确表明出错时才触发反思外部验证优先能用测试验证的就跑测试不要让模型自己判断自己对不对。编译器永远比内省可靠。错误恢复不要从头重来AgentDebug2025的核心洞察当Agent失败时不要从头重跑整个任务先定位失败点在执行链的哪个位置然后只从那个点重新执行。两类根因记忆错误Agent忘了关键信息上下文被截断、检索没命中→ 修复补充记忆从遗忘点重跑推理错误Agent从正确信息中得出了错误结论 → 修复换推理策略从错误决策点重跑效果成功率提升26%。错误分类决定恢复策略错误类型策略示例瞬态重试指数退避API超时、限流语义换策略模型被内容过滤阻断→改写prompt规划从当前状态重新规划原计划不可行记忆重新检索上下文关键信息丢失不可恢复升级到人类任务本身不可能VIGIL2025更进一步运行时持续监控Agent行为检测到异常循环、延迟飙升、输出退化时自动诊断并生成修复方案不需要等到任务完全失败。人机协作架构的一部分不是兜底Human-in-the-Loop不是Agent不行了找人帮忙它是架构设计的一部分——在特定的节点上人类介入是比自动化更优的选择。何时交给人类不可逆操作前删除数据、发布上线、发送邮件信心低于阈值模型不确定但又无法通过更多计算变得确定检测到异常模式循环、矛盾、持续失败Red-Flagging高价值决策影响大但频率低的判断人类检查点的位置应该预先设计好而不是失败了就问人。好的人机协作像高速公路上的收费站——在关键节点短暂停下确认而不是随时随地可能被打断。第六部分四层耦合 —— 一个完整的例子四层不是独立的用一个代码修复Agent的完整执行过程来展示它们之间的耦合任务修复一个GitHub Issue——“用户注册时邮箱验证不生效”代码库的初始状态auth/register.py处理注册逻辑auth/validators.py里已有validate_email函数但register.py从未调用它。第一轮循环感知Agent读取Issue描述相关代码文件auth/register.py。ACI设计决定了它看到的是带行号的代码片段而不是整个文件。决策ReActThought: Issue提到邮箱验证不生效。我需要找到验证逻辑在哪里。 Action: Search[email_validation in auth/]行动搜索工具执行返回auth/validators.py:23有一个validate_email函数。反馈环境反馈搜索成功返回结果→ 更新感知现在知道了验证函数的位置第二轮循环感知读取auth/validators.py的第20-40行。决策Thought: validate_email函数存在但register函数没有调用它。问题在register.py而不是validators.py。 Action: Edit[auth/register.py, line 45, add: if not validate_email(email): raise ValidationError(...)]行动编辑工具执行修改。反馈运行测试 → 测试失败。Error: NameError: validate_email is not defined第三轮循环反思触发反馈 → 感知更新测试失败的错误信息进入上下文。Agent同时触发Reflexion“我忘了添加import语句。”决策Thought: 我需要在文件顶部import validate_email。 Action: Edit[auth/register.py, line 3, add: from auth.validators import validate_email]行动编辑执行。反馈运行测试 → 全部通过 ✓四层耦合关系耦合表现设计影响感知 × 决策搜索结果的格式直接影响推理质量ACI设计决定了决策层的输入质量决策 × 行动添加验证的规划粒度必须匹配Edit工具的能力规划粒度要适配工具粒度行动 × 反馈Edit的返回成功不够需要测试才能验证真正的正确性行动结果 ≠ 任务成功需要独立验证反馈 × 感知测试失败的错误信息反思下一轮的新感知反馈质量决定了下一轮感知的信息量如果四层之间的接口设计不匹配系统性能会远低于各层单独的能力。一个优秀的决策层配上一个返回raw dump的感知层整体表现会很差。SWE-agent的实验证明了这一点——改善感知层的格式ACI在不改变决策层的情况下整体性能翻了3倍。第七部分工程实践Checklist架构选择决策树你的任务步骤是否固定 ├── 是 → Workflow │ ├── 步骤独立→ Parallelization │ ├── 步骤有序→ Prompt Chaining │ └── 需要分流→ Routing └── 否 → 步骤数可预测吗 ├── 是 → Orchestrator-Workers └── 否 → Agent自主循环 ├── 常规任务 → ReAct ├── 需要从失败中学习 → Reflexion └── 高价值复杂决策 → LATS四层设计清单感知层观察格式是否用了模型训练数据中的自然格式长期记忆是否有语义检索机制是否有上下文压缩/裁剪策略关键信息是否放在prompt首尾工具输出是否结构化而非raw dump决策层循环复杂度是否匹配任务复杂度不过度规划是否有任务分解一步不做太多事是否有终止条件最大轮次token预算失败时是否有回退策略行动层工具定义是否包含示例、边界、失败行为工具数量是否控制在10个以内或动态加载是否有执行沙箱不可逆操作是否有确认机制相似工具之间的边界是否写清楚了反馈层是否有确定性验证测试/编译/类型检查反思机制是否有次数限制≤3错误是否分类处理瞬态/语义/不可恢复是否有人类升级路径反馈信息是否足够具体定位到行/函数/原因常见坑与修复坑症状根因修复感知过载模型忽略关键信息、回答偏题上下文太长或格式混乱JIT检索注意力工程规划过深计划完美但执行偏离前几步的假设就错了用ReAct替代长期规划工具过多频繁选错工具工具描述重叠、数量超限动态加载Top 5-10反思过度正确答案被改成错误无限自我怀疑限2-3次外部验证优先无终止条件无限循环、成本失控缺少退出机制轮次上限token预算双保险反馈缺失错误累积不可逆每步执行后无验证每步验证状态检查点层间不匹配各层单独可用但组合表现差接口格式不兼容检查各层输入输出格式是否对齐一个最小可运行的Agent骨架defrun_agent(task:str,tools:list,max_turns:int20):history[]memoryload_long_term_memory(task)forturninrange(max_turns):# 感知层组装上下文contextassemble_context(system_promptSYSTEM,toolsselect_relevant_tools(tools,history),# 动态工具加载memorymemory,historycompress_if_needed(history),# 上下文管理tasktask)# 决策层模型推理responsellm(context)# 终止条件ifnotresponse.tool_calls:returnresponse.text# 行动层执行工具forcallinresponse.tool_calls:resultsandbox_execute(call)# 沙箱执行history.append({call:call,result:result})# 反馈层验证ifshould_verify(response.tool_calls):verificationrun_tests()# 确定性验证ifnotverification.passed:# 触发反思reflectionreflect(history,verification.error)memory.add_episode(reflection)returnMax turns reached without completion这30行代码覆盖了四层的核心逻辑。生产级系统在此基础上增加错误分类与恢复、人机检查点、可观测性日志/追踪、持久化跨会话状态。总结回顾Agent架构的四层设计核心线索很清晰Agent不是模型能力的简单外延而是一个完整的控制系统。感知层决定了模型能看见什么——ACI设计、记忆架构、上下文管理每一环都在对抗信息腐化决策层决定了模型怎么选择下一步——从ReAct的单线执行到LATS的树搜索计算代价和能力上限同步增长行动层决定了模型能对环境做什么——工具设计、动态加载、安全边界花的精力应该超过prompt调优反馈层决定了模型怎么知道做对了——从确定性验证到人类升级路径闭合了控制环路四层之间的耦合关系往往比各层单独的能力更重要。一个优秀的决策层配上一个返回raw dump的感知层整体表现会很差。SWE-agent的实验证明了这一点——改善感知层的格式在不改变决策层的情况下整体性能翻了3倍。对于正在构建Agent系统的工程师最务实的建议是从最简单的方案开始用Workflow解决能解决的问题只在复杂度确实需要时才升级到Agent。每一层的设计都要有明确的工程约束上下文有上限、工具有数量限制、反思有次数限制、规划有粒度要求。Agent工程化的核心不是追求最复杂的架构而是在确定性和灵活性之间找到正确的平衡点。延伸阅读CoALAarXiv:2309.02427Anthropic: Building Effective AgentsLilian Weng: LLM Powered Autonomous AgentsReActarXiv:2210.03629→ ReflexionarXiv:2303.11366→ LATSarXiv:2310.04406Agent Patterns Atlasagents.kour.me