1. 从能跑通到会思考harness 工程到底卡在哪一步如果你最近在折腾 Agent 项目大概率已经踩过这样一个阶段模型接上了工具调通了任务也能跑完但整个系统就是透着一股死板的味道。你给它一个指令它按部就班执行你换一个稍微绕一点的场景它立刻开始胡言乱语或者陷入无限循环。这不是模型不行而是你的 harness 工程还停留在管道工层面——只负责把输入接到输出中间没有任何认知层面的调度。我做了几年 Agent 系统从最早的 prompt 拼接到后来的 function calling 编排再到现在的多 Agent 协作最大的感受是harness 工程解决的是能不能跑认知工程解决的是跑得对不对、好不好、稳不稳。这两者之间的差距不是加几个工具、换一个更强的模型就能填上的它需要你在架构层面重新思考 Agent 的决策逻辑。先把这个概念说清楚。所谓 harness在 Agent 语境下指的是包裹在模型外面的那一层执行框架——它负责管理上下文、调度工具、处理返回值、控制循环。你可以把它理解成 Agent 的操作系统外壳。而认知工程是在这个外壳之上再叠加一层关于怎么想的设计什么时候该反思、什么时候该放弃、什么时候该换策略、什么时候该向用户求助。前者是骨架后者是大脑。为什么现在大家都在聊这个话题因为单纯堆 harness 已经遇到瓶颈了。你去看那些热词——agent 记忆、agent 架构、agent 安全、agent evals——本质上都是在问同一个问题怎么让 Agent 从执行器变成决策者。harness 工程能帮你把工具接好、把流程串起来但它没法告诉 Agent当前这个方案已经试了三次都失败了该换一条路。这个判断必须由认知层来做。我见过太多项目卡在这个坎上。团队花了两周把 harness 搭得漂漂亮亮工具注册、参数校验、错误重试全都有结果一上真实场景就崩。原因很简单真实世界的任务不是线性的它充满了歧义、中断、意外和需要权衡的取舍。你的 harness 再健壮如果 Agent 本身不会想那它永远只能处理那些被完美定义过的任务。所以这篇文章想聊的不是怎么从零写一个 harness——那个网上教程已经够多了。我想聊的是当你已经有了一个能跑的 harness 之后怎么把它升级到认知工程的层面。具体来说我会拆解四个核心问题认知层到底要管什么、元认知怎么落地、记忆系统怎么设计才不是摆设、以及怎么评估一个 Agent 是不是真的会思考了。每个部分我都会给出可操作的思路和踩过的坑不玩虚的。2. 认知层要管的四件事不是加个 prompt 就叫认知工程很多人对认知工程的理解停留在加一段 system prompt 让模型多想想。这太浅了。真正的认知层需要在 harness 的执行循环里嵌入四个明确的决策节点每个节点都有对应的机制和触发条件。2.1 任务分解从一步到位到分而治之的触发时机harness 工程的默认模式是给一个任务调一次模型执行一个动作。但真实任务往往需要多步。认知层要做的第一件事就是判断当前任务是否需要分解。这个判断不能靠模型自己感觉得有明确的信号。我的做法是在 harness 里加一个前置评估节点当任务满足以下任一条件时强制进入分解流程——任务描述超过一定长度、涉及多个不相关的实体、或者历史执行中同类任务的失败率超过阈值。分解的方式也不是让模型自由发挥而是要求它输出结构化的子任务列表每个子任务必须包含目标、输入、预期输出、依赖关系四个字段。这里有个坑我踩过早期我让模型自由分解结果它把帮我订一张去北京的机票分解成了1. 确定出发地 2. 确定目的地 3. 确定时间 4. 搜索航班 5. 下单。看起来合理但第 1 步和第 3 步的信息其实用户已经给了模型只是在凑步骤。后来我改成先做信息完整性检查再做分解把已知信息抽出来作为约束分解出来的子任务数量直接少了一半。2.2 策略选择同一个目标为什么这次不走上次的路这是认知工程和 harness 工程最本质的区别。harness 工程是给定输入执行固定流程认知工程是给定目标选择当前最优策略。具体怎么落地我在 harness 的执行层上面加了一个策略注册表。每个策略是一个独立的执行模板比如直接回答搜索后回答调用工具链请求澄清放弃并报告。当 Agent 接到任务时认知层先根据任务类型、历史成功率、当前上下文长度等特征选一个策略出来再交给 harness 执行。策略选择的关键是要有反馈闭环。我一开始只做了选择逻辑没做效果追踪结果 Agent 永远选同一个策略因为它不知道别的策略效果更好。后来我在每次执行后记录策略-任务类型-结果三元组用一个简单的统计模型来更新策略权重。这个改动让 Agent 在遇到模糊任务时主动请求澄清的比例从 5% 提升到了 40%整体任务完成率涨了将近一倍。2.3 异常处理当工具报错时Agent 应该想什么harness 工程处理异常的方式通常是重试三次然后报错退出。认知工程要问的是这个错误意味着什么该重试、该换工具、还是该改变整个方案我把异常分成了三类每类对应不同的认知响应异常类型典型场景认知响应瞬时错误网络超时、限流退避重试不改变策略参数错误工具返回参数校验失败重新推理参数必要时请求澄清方案错误连续多次同类失败触发策略切换重新分解任务这个分类看起来简单但落地时有个细节很关键判断连续多次同类失败不能只看次数要看失败模式是否相同。我试过单纯按次数触发结果 Agent 在遇到一个需要多次尝试才能成功的任务时被误判为方案错误提前切换了策略反而搞砸了。后来改成相同错误码连续出现三次才触发切换准确率好很多。2.4 终止判断什么时候该停下来这是最容易被忽略的一环。harness 工程通常只处理成功和失败两种终止状态但认知工程需要更细的粒度任务完成了、任务部分完成了、任务无法完成但可以给出有用信息、任务需要人工介入。我在实际项目里加了一个置信度评估节点。每次执行完一个子任务后认知层会评估当前结果对最终目标的贡献度。如果贡献度低于阈值且剩余步骤的预期收益也不高就主动终止并报告部分完成。这个机制救过我好几次——有一次 Agent 在搜索一个不存在的数据时没有无限循环而是在第三次搜索无果后主动说我尝试了三种搜索方式都没找到建议你确认一下数据源用户体验反而比硬撑着跑完要好。3. 元认知落地让 Agent 知道自己不知道元认知这个词听起来很玄但落地到 Agent 系统里它其实就是一个很具体的问题Agent 能不能准确评估自己的能力边界。这件事做不好前面所有的认知设计都是空中楼阁。3.1 置信度校准为什么模型说我很确定的时候往往最不靠谱大模型有个通病它对自己的输出过度自信。你问它一个它完全不知道的问题它也能编出一段看起来很有道理的回答而且语气笃定。这在 harness 工程里不是问题——反正它输出什么就执行什么。但在认知工程里这是致命的因为认知层需要根据置信度来决定是否继续、是否求助、是否切换策略。我的做法是不信任模型自报的置信度而是用外部信号来校准。具体来说我会综合以下几个维度一致性检验让模型用两种不同的方式回答同一个问题看结果是否一致。不一致说明它在这个问题上不稳定。证据追溯要求模型在给出结论时附带依据来源。如果依据是根据我的知识这种模糊表述置信度直接打折。历史准确率按任务类型统计模型的历史表现作为先验概率。这三个信号加权后得到的置信度比模型自己说的靠谱得多。我实测下来经过校准的置信度评估在该不该请求澄清这个决策上准确率从原来的六成提升到了八成五以上。3.2 能力边界探测怎么让 Agent 主动说这个我搞不定光有置信度还不够还得有触发机制。我在认知层里设了三条红线任何一条触发Agent 就必须停止自主执行转为请求澄清或报告限制连续两次置信度低于阈值说明当前路径可能根本走不通。关键信息缺失且无法推断比如用户说帮我处理一下那个文件但没说是哪个文件历史上下文里也找不到。涉及高风险操作且置信度不足比如删除数据、发送消息、执行支付这类操作必须高置信度才放行。这里有个经验红线阈值不能设死要按任务类型动态调整。我一开始用统一阈值结果在创意类任务上过于保守Agent 动不动就求助用户觉得很烦在数据类任务上又过于激进经常给出错误结果。后来改成按任务类型配置不同的阈值矩阵体验才正常。3.3 反思循环执行完之后Agent 应该复盘什么元认知的最后一环是反思。harness 工程执行完就结束了认知工程要求 Agent 在每次执行后做一次简短复盘。复盘的内容不是我做了什么而是我哪里做得好、哪里可以改进、下次遇到类似情况该怎么办。具体落地时我要求复盘输出三个字段有效动作、无效动作、下次策略建议。这三个字段会被写入记忆系统在后续遇到同类任务时作为参考。这个机制的效果不是立竿见影的但跑上一两百个任务之后Agent 在同类任务上的平均执行步数会明显下降。有个细节要注意反思不能太频繁也不能太笼统。我试过每个子任务都反思结果 token 消耗暴涨而且大部分反思都是废话。后来改成只在任务整体结束后反思一次且要求反思必须引用具体的执行记录不能空泛地说下次要更仔细。4. 记忆系统不是存得越多越好而是取得越准越好聊 Agent 就绕不开记忆。但我发现很多项目的记忆系统就是个摆设——存了一堆对话历史检索的时候要么全量塞进上下文要么随机取几条根本没起到认知支撑的作用。认知工程对记忆的要求不一样记忆不是为了记住而是为了用上。4.1 三层记忆架构工作记忆、情景记忆、语义记忆我在项目里把记忆分成三层每层的用途和存储方式都不同工作记忆是当前任务的临时上下文生命周期就是一次任务执行。它存在内存里任务结束就清掉。这层的关键是控制长度我一般限制在模型上下文窗口的 30% 以内超了就做摘要压缩。情景记忆是历史任务的执行记录包括任务描述、执行步骤、结果、反思。这层存在外部存储里按时间索引。它的用途是遇到类似任务时参考上次怎么做的。语义记忆是从多次执行中抽象出来的规律和偏好比如用户喜欢简洁的回答这类任务用搜索策略比直接回答成功率高。这层是最高级的也是最能体现认知工程价值的。三层之间的流转关系是工作记忆在任务结束后经过摘要写入情景记忆情景记忆积累到一定量后通过归纳生成语义记忆语义记忆在执行新任务时作为策略选择的先验输入。4.2 检索策略为什么向量相似度经常不靠谱大部分人的记忆检索就是用向量数据库做相似度搜索。我一开始也这么干后来发现两个问题一是相似度高不代表有用二是很多关键记忆跟当前任务的字面相似度很低。举个例子。用户问帮我分析一下上个月的销售数据向量检索可能会召回一堆跟销售数据分析相关的记忆。但真正有用的可能是三个月前的一条记忆用户上次说销售数据要按区域拆分不要只看总数。这条记忆的字面相似度不高但它是关键约束。我的解决方案是混合检索向量相似度只占一部分权重另外加入任务类型匹配、时间衰减、用户显式标记等信号。具体权重我调了很久目前的配置是向量相似度 40%、任务类型匹配 30%、时间衰减 20%、显式标记 10%。这个配置不一定适合所有人但思路可以参考别让向量相似度一家独大。4.3 遗忘机制主动删掉比拼命记住更重要这是最反直觉的一点。很多人觉得记忆越多越好但实际跑下来过时的、错误的、低质量的记忆会严重干扰 Agent 的判断。我在系统里加了遗忘机制规则有三条一是超过一定时间且从未被检索到的记忆降权处理二是被后续执行证明是错误的记忆直接标记失效三是与语义记忆冲突的情景记忆以语义记忆为准。这个机制上线后Agent 在长期任务上的表现明显更稳定了。之前经常出现的情况是Agent 引用了一条三个月前的过时信息导致整个方案跑偏。现在这种情况基本没有了。5. 评估体系怎么判断一个 Agent 是真的会思考最后一个问题也是最难的一个你怎么知道你的认知工程改造是有效的harness 工程的评估很简单看任务成功率、看响应时间、看错误率。但认知工程的效果这些指标反映不出来。5.1 过程指标不只看结果还要看怎么走到结果的我现在的评估体系里过程指标占了一半权重。具体包括策略切换次数在遇到障碍时Agent 是否尝试了不同策略还是死磕一条路。澄清请求质量Agent 请求澄清时问的问题是否精准还是泛泛地问你能再说清楚点吗。无效步数占比执行过程中有多少步是对最终结果没有贡献的。反思采纳率Agent 在后续任务中是否真的用上了之前反思得出的建议。这些指标比单纯的成功率更能反映认知能力。我见过一个 Agent任务成功率很高但策略切换次数几乎为零——说明它只擅长处理那些它已经会处理的任务遇到新情况就歇菜。这种 Agent 在真实场景里是很脆弱的。5.2 对抗测试用坏输入逼出认知短板常规测试用例都是精心设计的测不出认知层的真实水平。我专门建了一套对抗测试集包含以下几类歧义任务故意给模糊的指令看 Agent 是瞎猜还是主动澄清。矛盾约束给出互相冲突的要求看 Agent 是否能识别并指出。中途变更任务执行到一半时改变需求看 Agent 能否平滑调整。不可能任务给出一个客观上无法完成的任务看 Agent 是无限循环还是及时止损。这套测试集跑下来认知工程的短板一目了然。我每次做架构调整后都会跑一遍对比各项指标的变化。5.3 长期追踪认知能力是养出来的不是调出来的最后说一个心态问题。认知工程的效果不是上线就能看到的它需要时间积累。记忆系统要跑够量才有统计意义策略权重要有足够反馈才能收敛反思机制要积累足够案例才能提炼出有价值的语义记忆。我的建议是至少跑够 500 个真实任务再做评估。前期指标波动很正常不要急着调参。我见过团队上线三天觉得效果不好就回滚了其实再跑一周可能就出效果了。认知工程本质上是在给 Agent 建立经验而经验这东西急不来。6. 我在实际项目里踩过的三个坑聊完方法论说点实在的。下面这三个坑是我在从 harness 工程往认知工程升级的过程中真实踩过的每个都让我重新思考了架构设计。6.1 认知层不能太重否则 harness 会被拖死我一开始把认知层做得特别复杂每次执行前要做任务分解、策略选择、置信度评估、记忆检索一套流程走下来光决策就花了十几秒。结果就是 Agent 变得极其犹豫简单任务也要想半天。后来我做了分级处理简单任务走快速通道跳过大部分认知节点复杂任务才走完整流程。判断标准是任务描述的长度和涉及的工具数量。这个改动让简单任务的平均响应时间从 12 秒降到了 3 秒以内复杂任务的决策质量没有下降。6.2 记忆检索不能同步做否则延迟爆炸早期我把记忆检索放在执行主流程里同步做每次都要等向量数据库返回。任务一多延迟就上去了。后来改成异步预取在任务开始时先触发一次检索执行过程中如果需要更多记忆再补充检索。这样大部分情况下记忆已经准备好了主流程不用等。6.3 反思机制不能只靠模型自省要有外部信号我最初让模型自己反思哪里做得好哪里做得不好结果它每次都说我做得很好下次继续保持。这种反思毫无价值。后来我改成用外部信号驱动反思只有当任务失败、或者用户给出负面反馈、或者执行步数超过预期时才触发反思并且要求反思必须引用具体的执行日志。这样反思才有针对性。7. 给正在做 Agent 项目的你几条实在建议如果你现在正在做 Agent 项目不管是在 harness 阶段还是已经想往认知工程走下面这几条建议可能对你有用。第一先把 harness 做扎实别急着上认知层。我见过太多项目harness 本身还一堆 bug就急着加记忆、加反思结果问题定位都定位不清楚。harness 是地基地基不稳上面盖什么都会塌。第二认知层的每个机制都要有明确的触发条件和退出条件。不要做永远在反思或者永远在检索这种设计那只会消耗资源不产生价值。每个机制都要能回答什么时候启动、什么时候结束、效果怎么衡量。第三评估体系要提前建不要等做完再想怎么测。认知工程的效果很难用单一指标衡量你需要一套组合指标。这套指标最好在动手改造之前就定好这样改造过程中才有方向。第四接受不完美。认知工程的目标不是让 Agent 变成完美决策者而是让它在该犹豫的时候犹豫、该果断的时候果断、该求助的时候求助。一个知道自己边界的 Agent比一个什么都敢答的 Agent 有价值得多。第五别闭门造车。Agent 这个领域变化太快了今天的最佳实践明天可能就过时了。多看看别人的项目多跑跑开源框架多跟同行交流。我很多灵感都是从别人的踩坑记录里来的。最后说一句从 harness 工程到认知工程本质上是从工程思维转向产品思维。harness 关心的是系统能不能跑认知工程关心的是用户能不能用得好。这个转变不容易但一旦转过来你做的 Agent 就不再是一个 demo而是一个真正能解决问题的工具。