做Agent快两年了我越来越觉得判断一个Agent靠不靠谱关键不是看它背后接的是多大的模型而是看它怎么决策。把一堆工具、提示词、记忆堆给LLM它确实能跑但跑起来经常是看起来聪明、用起来呆——要么突然绕圈子要么调错工具要么把上下文搅成一锅粥。这个问题的根源很多时候不是模型能力不够而是我们没把Agent的决策机制当作一个工程问题去设计。所谓认知工程就是干这件事的把Agent的感知、记忆、推理、行动拆成可设计、可度量、可迭代的模块而不是让大模型在一个黑盒里自生自灭。在这个方向里我认为最值得借鉴的一套框架是卡尼曼提出的System1快系统与System2慢系统双模型。快系统负责直觉、快速、低开销的判断慢系统负责理性、缓慢、高开销的推理。放到Agent架构里这就不是一个心理学概念了而是一套非常实用的工程路线高频简单的场景走快通道复杂高风险的任务走慢通道。这篇文章我会把这块的架构设计、落地细节、踩坑经验和盘托出适合正在做Agent开发、或者想系统学习Agent认知架构的朋友参考。1. 为什么Agent需要认知工程1.1 Agent的决策到底难在哪很多人刚接触Agent时会觉得决策不就是让LLM自己选一条路走吗给个Prompt说你是助手请规划并执行任务模型自然就会调用工具、组织步骤。早期我也是这么干的但实际跑下来问题非常多。一个典型的Agent决策链路是感知输入 → 召回记忆 → 判断意图 → 制定计划 → 调用工具 → 观察结果 → 修正计划。这条链路里每一步都是概率性的。LLM判断意图可能错记忆检索可能跑偏工具调用参数可能生成错观察结果后可能不知道该不该重试。单步成功率如果是90%五步链路下来成功率就只有59%了。这就是Agent项目最常见的单测全过端到端全挂现象。更难搞的是决策是上下文相关的。同一个问题用户在对话第五轮问和第一轮问Agent该走的路径可能完全不同同一个工具在A场景下是正确选择在B场景下就是误判。如果我们把所有决策压力都丢给大模型那Agent的行为就变得难以预测、难以调试。你没办法说清楚它为什么选了这个工具也就没办法针对性改进。认知工程解决的就是这个不可预测性。它要求我们把Agent的决策过程从模型的自由发挥变成系统的可控设计。哪些信息进入决策、用什么规则判断、什么情况下交给模型、什么情况下直接走固定流程——这些都是工程问题应该由我们设计者决定而不是交给概率。1.2 System1与System2不是心理学名词是架构思路《思考快与慢》里面有一个经典的双系统模型。System1是自动化的、快速的、近乎直觉的反应比如你看到红灯会自然停下System2是费力的、需要专注的思考比如心算一道复杂的乘法题。传统上这是对人类认知的描述但放到Agent里它直接对应了两类截然不同的计算路径。System1在Agent中的映射是那些低开销、确定性强的决策用规则判断意图、用查表选择工具、用缓存直接复用过去的答案。它的特点是快、便宜、可解释。System2在Agent中的映射则是让大模型进行深度的链式思考、多步规划、多Agent协商它慢、贵但能处理新情况和复杂目标。我当时看完这个框架后最大的启发是大多数Agent的设计者只做了System2没有System1。所有请求不管简单的还是复杂的统统塞给大模型去思考。结果就是简单问题被过度处理延迟高、成本高、还有可能被模型想歪。认知工程的起点就是把快慢两条通道拆开让该快的快起来该慢的慢下去并在中间加一个可控的调度器。2. 把System1装进Agent快决策通道的工程实现2.1 快决策不是弱智决策很多人一听快系统第一反应是它只能处理你好、再见这种简单话术。实际上不是。快系统的定位是利用一切可复用的经验跳过推理过程直接给出决策它完全可以用在今天的大量真实场景里。举两个例子。第一个是客服Agent的退款场景。用户说我要退款如果你走完整的LLM规划链路它会先分析意图、再检索订单、再查看退款政策、再决定执行哪个工具。这个过程可能要调用5次模型耗时几十秒。但如果我们把退款意图和订单查询退款接口绑定做一条预设的流程大部分时候直接走这条流程就够了又快又不会出错。第二个是代码Agent的场景。一个高频工具是文件读取当用户说看一下src目录下的utils.py时Agent如果还要慢悠悠地判断该用什么工具那效率就很糟糕。直接用文本匹配或向量匹配锁定工具然后执行体验会好非常多。所以快决策的本质是把经验固化成路径。它一点都不弱智恰恰是系统越成熟、沉淀的路径越多Agent才越像老手——新手才需要每件事都停下来想半天老手一看场景就知道怎么办。2.2 快路径的典型组件我实际落地快系统时用得最顺手的组件有四类。第一是意图路由规则。这里不一定要上多复杂的模型正则表达式、关键词表、或者一个几百MB的小型文本分类器都能做。判断查天气问时间查快递这类高频意图完全不需要大模型出马。Python里甚至可以直接用if判断加一个简单的语义匹配库搞定。第二是记忆缓存复用。同一个用户问过的问题、同一种任务的结果都可以缓存。我之前做过一个调研Agent用户连续追问XX公司2024年营收是多少第一问走了完整的搜索和分析链路第二问同会话内如果直接命中缓存就能秒回。这里的关键是设计好缓存key至少要包含用户ID、意图、关键实体的组合。第三是工具路由表。每个工具绑定一段描述和触发条件用一个轻量的检索器比如embedding加余弦相似度做工具选择。门槛阈值设得高一些只有匹配度很高时才走快路径。这里可以做成一张表工具名、触发关键词、参数模板、关联权限。有了这张表Agent选工具的逻辑就不需要每次都问模型。第四是预设模板与技能绑定。代表作有技能Skill管理。技能就是一组封装好的行为序列针对某类任务先做什么、后做什么、用什么工具、输出什么格式全部预定义。Agent在识别到对应的任务域后直接调用这个技能脚本而不是现场让模型编排。# 简化版的快路径决策器 def fast_decision(user_input, session): # 1. 命中会话缓存 cache_key f{session.user_id}:{hash(user_input)} if cached : cache.get(cache_key): return {type: cache, data: cached} # 2. 命中明确意图规则 intent classify_intent(user_input) if intent in RULE_TABLE: action RULE_TABLE[intent] return {type: rule, intent: intent, action: action} # 3. 高置信度工具路由 tool route_tool_by_embedding(user_input, threshold0.85) if tool: return {type: tool, tool: tool} # 4. 都不行交给慢系统 return {type: fallback_to_system2}2.3 快路径的判据与安全阀快路径最大的风险是误判。你把一个复杂请求当成简单请求处理了结果答非所问。所以我一直强调快路径必须带置信度和安全阀两个东西。置信度就是每个快路径决策都要产出可信度评分。规则命中时可以给规则本身设一个权重语义路由时用相似度分数缓存命中时要考虑缓存的时间衰减。我通常会设一个分层阈值高于0.9直接执行0.7到0.9之间执行但附带可撤销选项低于0.7不允许走快路径强制降级到慢系统。安全阀的作用是让快路径敢犯错、能纠正。比如快路径执行的工具操作是只读的、无副作用的那就可以放心用但如果涉及写操作、发消息、下单这种不可逆动作即使是高置信度我也要求触发一层慢系统复核。一句话总结快路径负责行动效率慢系统负责行动安全。3. 慢系统仍然不可替代复杂决策的推理通道3.1 什么时候必须切换慢系统快系统再强也只能处理见过的情况。Agent真正有价值的地方恰恰在于处理没见过的情况。慢系统就是为了这个存在的。按我自己的项目经验出现下面几种情况时必须切慢系统。第一是目标冲突。比如用户说尽量便宜但又要最快送达给一个配送Agent这俩目标天然有冲突。快路径没法处理只能让慢系统做权衡甚至需要多轮澄清。第二是信息不完整。用户的需求缺关键参数比如订机票没说日期、查报告没说时间范围。慢系统需要制定追问计划一步步补齐信息而不是瞎猜。第三是多步依赖。任务需要先查询A用A的结果决定B怎么查再综合A和B输出C。这种链式依赖快路径的预设流程很难覆盖必须动态规划。第四是高风险动作。前面说的不可逆操作即使意图明确也建议让慢系统过一遍把风险点、备选方案、可能后果列出来。3.2 慢系统的经典实现模式慢系统的实现并不是简单地把Prompt写长一点。核心是给Agent一个显式的思考与行动循环。现在业界最常用的还是ReAct模式Thought思考→ Action行动→ Observation观察→ 循环。每一步模型都产出一个思考然后调用一个工具观察结果接着再思考下一步。这个模式的优点是步骤透明、容错性好哪一步错了都看得见。我更喜欢的是Plan-and-Execute这个变体。它先让模型把所有步骤规划好形成一个任务清单然后逐项执行中间根据结果修订计划。相比ReAct它减少了反复决策的次数更适合任务边界清晰、执行链路长的场景。还有一个模式是Reflexion反思它让Agent在失败后回顾整个决策过程把犯过的错写进记忆下次不再犯。我强烈建议在慢系统里加一层反思机制它是Agent能越用越聪明的关键。多Agent协作也属于慢系统范畴。让一个Agent做规划者、一个Agent做执行者、一个Agent做评审者互相纠偏。代价是延迟和成本成倍增加所以它只配给真正复杂、容错率低的任务用。3.3 快慢协同双通道调度有了快通道和慢通道接下来最关键的就是调度器谁来决定走哪条路这是我做认知工程时花时间最多的地方。我的做法是做一个分级调度器。第一级先把用户请求放进快路径的判据里包括意图匹配度、缓存命中情况、风险等级三个维度。都合格走快路径有一项不合格进慢系统。慢系统也不是每次都跑完整的ReAct循环我加了一个轻量慢路径只让模型做一步规划然后再回快路径执行。这个折中方案特别适合那种方向需要判断执行很明确的任务成本只增加了一次模型调用效果提升却很大。还要设计超时降级。慢系统推理时间超过阈值比如30秒时自动切回快路径先给用户一个基于经验的答复再异步把慢系统的更优结果推送给用户。这套先回答后完善的模式对提升体验非常有效。4. 认知工程落地记忆、技能与评估4.1 记忆分层短期、长期与动态决策快照决策不可能在真空中进行。Agent做决策时依赖的记忆我认为至少要分三层来设计。短期记忆就是当前会话的上下文窗口。这一层特别容易犯的错是无脑把所有历史都塞给模型导致上下文爆炸。正确的做法是维护一个会话摘要每几轮对话后让模型把关键信息压缩成摘要只保留重点。中期记忆可以理解成工作记忆存放当前任务链中产生的中间结果比如已经查到的数据、待执行的子任务清单。长期记忆是跨会话的知识一般用向量数据库存语义用知识图谱存实体关系。我特别想讲的是动态决策快照这个词它是我在做复杂Agent时总结出来的一个实践。所谓决策快照就是把Agent在某个决策时刻所需的全部关键信息打包成一个结构化的对象包括当前目标、已有信息、缺失信息、可用的工具、风险等级、历史教训。每次进入慢系统前先构建这个快照然后让模型基于快照推理。这么做的好处是模型不用在稀疏的长上下文里自己找重点决策质量会稳定很多。4.2 技能编排Skill和Agent的区别热词里有skill和agent的区别和harness和agent区别这块我多说几句因为它是认知工程落地时绕不开的概念。Skill是原子化的能力封装本质是一段可执行的流程或函数。比如查天气Skill、生成周报Skill它规定了输入参数、执行步骤、输出格式。Skill本身不做决策它只负责把一件事做好。Agent则是一个决策主体它决定什么时候调用哪个Skill、怎么组合多个Skill以及如何评估执行结果。简单类比Skill是员工的手Agent是员工的大脑。Harness则是夹在Agent和模型之间的那层控制装置负责管理上下文窗口、工具注入、输出解析、安全过滤。把三者分开设计最大的好处是替换成本低Skill可以独立升级Harness负责统一管控Agent只聚焦决策逻辑。我见过很多项目把这些东西全揉在一个Python类里结果换一个工具就牵一发动全身。4.3 评估与监控决策质量怎么量化不量化的认知工程都是玄学。我建议至少跟踪五类指标。第一类是任务成功率这个最直接整个任务跑完并产出正确结果的比率。第二类是平均决策步数也就是Agent从收到请求到完成任务总共做了多少次模型调用。步数越多说明决策链路越繁琐也意味着延迟和成本越高。理想状态下简单任务的决策步数应该在1到2步复杂任务控制在5到8步。第三类是快路径命中率它可以反映你的经验沉淀是否足够命中率太低说明规则和缓存没建好。第四类是误判率特别要统计快路径误判导致结果出错的比例。第五类是延迟与成本分开统计快路径和慢路径各自的token开销和响应时间。有了这些指标Agent的迭代就很清楚了快路径命中率低就去补规则和技能误判率高就把对应场景降级到慢系统决策步数太多就去精简Prompt和工具描述。我一般每个迭代周期都会跑一版回归数据集把之前遇到过的50到100个典型case灌进去看成功率有没有回退。这是防止改好一个bug、引出三个bug的有效办法。5. 实操一个带双通道调度器的Agent样例5.1 整体架构与代码骨架这里我给出一个可直接参考的简化实现。整体架构分三层感知层、调度层、执行层。感知层负责把用户输入转成统一的请求对象调度层先走快路径不满足条件再走慢路径执行层统一调工具和Skill。from dataclasses import dataclass from typing import Optional dataclass class DecisionSnapshot: goal: str known_info: dict missing_info: list available_tools: list risk_level: str context_budget: int class AgentCore: def __init__(self, fast_decider, slow_reasoner, executor): self.fast_decider fast_decider # System1 self.slow_reasoner slow_reasoner # System2 self.executor executor def handle(self, user_input, session): # 1. 感知层构造决策快照 snapshot self.build_snapshot(user_input, session) # 2. 调度层快路径决策 fast_result self.fast_decider.decide(user_input, snapshot) # 3. 快路径带置信度高风险任务强制复核 if fast_result.confidence 0.85 and snapshot.risk_level ! high: return self.executor.run(fast_result.action, snapshot) # 4. 低置信度或复杂任务慢系统精调 plan self.slow_reasoner.plan(snapshot) result self.executor.execute_plan(plan, snapshot) return result这个骨架看起来简单但有几个细节值得注意。一是build_snapshot里要对长期记忆做检索把相关的历史教训塞进快照二是fast_decider内部要维护LRU缓存避免同一个用户短时间内重复问题反复走流程三是慢系统的Prompt要基于快照动态生成而不是写死一段模板。5.2 慢系统Prompt模板实例慢系统能不能稳定决策Prompt模板很关键。我用的模板大概长这样你是一个谨慎的决策规划器。请基于以下快照信息制定执行计划。 【当前目标】{goal} 【已知信息】{known_info} 【缺失信息】{missing_info}若为空表示信息已充足 【可用工具】{available_tools} 【风险等级】{risk_level}high表示任何动作前需提供风险说明 要求 1. 如果缺失信息导致目标无法推进只输出追问列表不要猜测。 2. 如果目标明确请按步骤列出 plan每步必须绑定一个可用工具。 3. 若是高风险动作必须额外输出 potential_risks 和 fallback。 4. 保持简洁每一步控制在50个字以内。这个模板的核心是限制模型的发散空间。如果你不限制模型很容易自由发挥编出一些不存在的工具或者跳过关键步骤。5.3 调优过程与真实数据我在一个内部工单处理Agent上实测过这套架构。改动前所有请求都走慢系统平均决策步数是4.2步平均响应延迟是12秒P95延迟到了30秒任务成功率78%。改造后我把查工单状态修改备注重新分配处理人三个高频意图固化成了技能接入快路径并做了一个简单的缓存。上线跑了两周后数据变成了快路径命中率41%整体平均决策步数降到1.9步平均延迟降到3.5秒P95降到8秒任务成功率提升到87%。失败率下降主要是因为慢系统不再被简单任务干扰能够把算力集中在真正复杂的问题上。41%的命中率听起来不算特别高但它已经消化了62%的用户请求量因为高频意图集中在少数几个场景里。你可以类比成一个餐厅如果招牌菜稳定出餐其他特色菜再慢慢做整体翻台率自然上去。6. 常见问题与排查技巧实录6.1 决策慢、反复调用大模型现象是Agent像卡壳一样一个简单任务调用五六次模型。排查思路先把链路打点。给每次模型调用记录触发原因、输入长度、输出长度、耗时。然后看触发原因分布。我遇到最多的原因是工具路由太弱模型不知道该选哪个工具于是反复在Prompt里列出候选工具、反复对比。解决办法是加强快路径的工具路由表让高置信度匹配直接在快路径里定下来。还有一个常见原因是观察结果没有评审机制模型拿到工具返回后不信任结果又调用一次模型确认。这种情况应该在技能定义里加一个结果校验步骤用确定性代码校验而不是让模型二次判断。6.2 快路径误判造成答非所问这是最打击信心的坑。你精心做了快路径结果用户问了个新场景被前面的规则误捕了。我踩过的真实案例是用户问我想退货客服Agent的退款规则没匹配上退货反而命中了查询订单的规则结果给用户报了一堆订单状态。用户当场就炸了。排查方法是在快路径日志里记录命中的规则输入文本相似度分。专门去捞随机样本看哪些规则容易被不相关文本命中。解决手段无非几个提高命中阈值、给规则增加否定词表、对涉及操作类的动作统一加保险丝——也就是前面说的操作类快路径命中也不直接执行必须过一道意图复核的轻量慢系统。这道保险丝把误判率从8%压到了1.5%代价仅仅是多花了一次小模型调用。6.3 上下文污染与记忆串线长期记忆用的时间越长越容易出现串线。Agent把上一个用户的经验套到当前用户身上导致决策完全跑偏。比如一个Agent从A用户那里学到偏好凌晨催办结果B用户凌晨收到催促体验极差。这个问题的本质是记忆检索的权限隔离没做好。我的解决措施是长期记忆的向量检索必须带元数据过滤用户ID、业务线、时间窗口检索出来的结果还要做一次相关性评分低于阈值的宁可不用。另外动态决策快照里的历史教训只允许来自当前任务域不要跨域引用。说到底记忆系统要遵循一个原则先隔离后共享只有在明确需要全局知识的场景下才放开跨用户、跨业务的检索。6.4 Agent、LLM和AI模型的区分热词里有人问DeepSeek是Agent还是LLM这是个好问题。简单说DeepSeek这类模型属于LLM大语言模型它们是提供语言理解和生成能力的大脑原料本身不行动、不调工具、不维护记忆。Agent则是构建在模型之上的系统它使用LLM做推理同时具备记忆、工具、规划这些组件。你可以把LLM理解成发动机Agent是整车——发动机决定动力上限但方向盘、刹车、导航这些认知工程的部分决定车到底能不能安全到达目的地。7. 写在最后的一点体会做认知工程时间越久我越觉得Agent开发的核心竞争力不在模型而在决策质量。模型会持续升级底座能力越来越强但如果没有好的System1和System2协同设计再强的模型也只是个被拉出来不停烧钱思考的愣头青。我现在的做法是每接到一个新Agent项目先不急着写Prompt而是花时间列一张表哪些场景是高频且明确的、哪些场景是低频且模糊的、哪些动作是高风险的。这张表就是认知工程的蓝图。快路径服务前两类场景慢系统兜底后两类调度器负责来回切换。按照这个思路走下来的Agent没有一个是不稳定的。最后分享一个细节快路径不要贪多。我最初总想把所有场景都固化成规则结果规则之间互相打架误判率暴增。后来学到教训每周只沉淀一两条真正经过验证的路径稳扎稳打。整套体系里敢于让慢系统处理新问题和善于让快系统处理老问题同等重要认知工程讲究的从来不是非此即彼而是动态平衡。