最近看到几篇围绕AI智能体Agent的科研论文投稿反馈题目各不相同被拒理由却指向同一个词判断力。论文里的Agent能规划任务、能调用工具、能跑完整流程模型版本也用到了当时的主流方案实验跑出来的结果并不差。可审稿人依然不买账问题恰恰出在Agent最核心的环节——它只证明了“能执行”没有证明“会判断”。这个现象不是个例。当前大量智能体项目正在经历同一道坎会用工具、能跑流程的系统越来越多但能回答“为什么要这样选”“结果是否可信”“什么时候应该停下来”的系统仍然稀缺。判断力才是智能体从玩具走向科研结论和生产系统的分水岭。这篇文章想把模糊的“判断力”拆开讲清楚它在Agent架构里的具体位置为什么评审会盯着它不放以及我们在工程和科研中怎么把判断力做成可验证的模块。读完你会理解一篇智能体论文被拒表面上败给了审稿人实际上败给了“系统缺少评估链”这一硬伤。1. 被拒的不是论文是一类缺少判断力的智能体架构1.1 从论文评审看“执行型Agent”的局限现在很多Agent相关论文重点都在“用大模型做规划、选工具、执行多步任务”。这类工作本身有价值它证明了LLM可以驱动复杂流程。但审稿人现在开始问一个更难的问题这一连串动作每一步都经过判断了吗如果Agent只是根据初始问题自动生成一串计划然后按计划调用工具最后把结果原样返回那它的行为本质上还是“把提示词工程延展成了多步脚本”。它和传统自动化脚本的区别只有一个计划是模型生成的。一旦计划错了、工具结果不可信、最终产出不符合目标系统本身没有检测能力也没有修正机制。论文评审的变化本质上是学术界在倒逼Agent从“流程自动化”走向“判断组织化”。你不仅要告诉读者系统做了什么还要告诉读者系统如何知道自己做得对。1.2 判断力智能体最容易忽略的第四要素常规Agent结构常被总结成模型、规划、工具、记忆四大要素。这四个要素解决的是“能做什么、怎么拆、用什么做、记不记得”但没有回答“做得对不对、该不该继续、结果能不能信”。判断力更像一个横切关注点需要嵌入到每一个环节里而不是单独做一块补丁。对科研论文而言少了判断力系统在评审眼里就成了“黑箱里的黑箱”用户输入和最终输出之间发生了什么主要由模型内在随机性决定工程上无法隔离、无法排查、无法复现。这也是被拒反馈里最扎心的地方不是你的模型不够强而是你的系统没有对自己的行为负责。2. 判断力在智能体架构中的真实位置2.1 一个类比优秀实习生和听话机器的区别把Agent想成刚入职的实习生。实习生能力强能写代码、查资料、出方案。但没有经验的实习生最容易出问题的地方往往不是干活不够快而是不知道什么时候该停下来问、什么时候该怀疑任务本身不合理、什么时候发现自己产出已经偏离目标。Agent也是一样的道理。一个只执行不判断的Agent就像从不提问的实习生它给出的答案可能是错的但它没有能力发现也没有意愿复核。所谓“判断力”正是让系统具备“自我怀疑”和“自我校验”的能力。2.2 六个关键判断节点在一个典型Agent任务中至少有六个节点需要判断力参与判断节点问题示例需求澄清用户请求是否足够明确用户说“优化一下报告”是否需要追问报告对象任务拆解拆成几步先后顺序如何先查数据还是先定结构工具选择是否真的需要调用工具直接回答即可还是必须查库结果校验工具返回是否符合预期返回为空、超时、字段缺失如何处理质量检查生成结果是否达标长度、格式、事实、引用是否满足需求终止判断继续迭代还是交付结果已通过检查还是需要人工介入每个节点都对应一类错误。如果一个Agent在这六个节点上都只依赖一次模型生成那它就不是在“判断”而是在“猜”。2.3 为什么流程编排不能替代判断现在很多低代码Agent平台比如Dify、Coze核心价值都是帮助开发者把节点编排起来。编排解决的是“流程确定性”判断解决的是“路径选择性”。可以这样理解流程编排是把一条从输入到输出的路径画出来判断力是让Agent在这条路径的交叉口具备“选择下一步”的能力。如果一个流程的所有转移都由人工预先写死那它本质还是传统工作流只是披了一层Agent的外壳。这也是为什么审稿人会格外关注判断力它决定了你做的到底是“一个可交互的流程图”还是一个“有自主决策能力的系统”。3. 评审为什么会揪住“判断力”不放3.1 可复现性判断过程必须是确定或可解释的科研论文的基本要求是别人可以复现。传统代码只要固定输入、固定参数就能得到一致输出。Agent却不同模型本身的温度参数、prompt微调、工具返回顺序都会影响判断结果。如果判断过程只是“让LLM自己决定”那换个模型版本、换次随机种子系统的表现可能完全不同。审稿人要的不是每次结果都一样而是“在这里判断判据是什么”。至少要把判断规则、模型版本、prompt版本固定下来并清楚交代哪些部分是可复现的、哪些部分有随机性。3.2 可观测性要有办法看到判断依据一个没有判断力的系统其实也很难排查。结果对了你不知道是哪个环节做对了结果错了你也不知道错在哪个判断节点。给Agent增加判断力不只是让系统更好用更是让系统“可观测”。每一轮决策都应该能输出依据为什么选择这个工具、为什么判定结果不合格、为什么决定终止任务。这些依据是调试的证据也是论文中的分析素材。3.3 可验证性判断力需要有自己的评测集判断力本身必须能被量化评估。比如构造100个测试任务其中60个明确不需要调用工具40个必须调用工具。一个合格的Agent应该能在这两类任务上做出正确选择。如果一个系统没有这种“判断力测试集”那“我引入了反思机制”就只能算一个功能描述而不是科研贡献。审稿人想看的是你在哪个维度上、用哪个指标、验证了判断力的提升。4. 构建判断力的四种主流技术方案4.1 显式规则与状态机稳定但笨拙最直接的判断方式是写规则。比如“数据库操作必须带WHERE条件”“输出文本长度不能超过N字”“工具返回为空时必须重试”。这些规则可以用状态机、策略模式或条件表达式实现。优点很突出透明、可控、可测试线上出问题能立刻定位。缺点也很明显开放场景覆盖不住。用户问题是不断变化的靠规则无法穷尽所有判断场景。所以规则适合做“安全兜底”不适合做“唯一判断来源”。4.2 模型自评与反思最常用的轻量手段Self-Critique是目前最流行的轻量判断方案。流程是先生成一版答案再让模型扮演评审人进行逐项检查最后根据评审意见修改答案。关键在于批评提示词的设计——不要问“你觉得对吗”而是要让模型按维度检查。比如要求它检查“是否回答了用户问题”“引用的数据是否有来源”“输出是否超过字数限制”。同时需要约定明确的通过信号比如让模型输出固定的“通过”字样否则容易出现模型自我感觉良好、循环修改停不下来的情况。这种方式的成本很低但稳定性有限。同一个模型既当选手又当裁判容易出现“自我偏好”所以更稳妥的做法是再叠加一个独立的判断模块。4.3 验证者模型让判断成为独立组件验证者模型Verifier的思路是把“判断”从“生成”中剥离出来。生成模型负责产出答案验证模型负责打分或判定。验证模型可以是一个训练好的分类器也可以是另外一个大模型从结构化维度输出结论。这种方式的好处是判断与执行解耦便于单独评测和调优。你可以先优化验证模型的准确率再反过来指导生成模型的迭代方向。缺点是需要额外投入训练数据或模型调用成本对个人开发者和中小团队来说门槛不低。4.4 多智能体协作把判断变成对话多智能体是当下热门方向设计思路是让多个Agent扮演不同角色比如“生成者”“批评者”“决策者”。通过多轮交流让不同视角互相校验从而提升判断质量。但要特别注意多智能体不等于有判断力。如果只是让多个LLM聊天没有明确的信息边界和决策规则系统很容易陷入“互相认同”或“无限循环”。要让协作真正产生判断力至少要满足三个条件分工清晰、信息有边界、终止有协议。5. 最小示例给Agent加上判断力层下面用一个最小Python示例演示“无判断Agent”到“有反思判断Agent”的演进。代码中使用占位函数call_llm表示模型调用实际运行时要换成具体模型SDK。5.1 示例1一个没有任何判断的执行Agent# 文件路径agent_without_judgment.py def call_llm(prompt: str) - str: # 实际项目中替换为具体模型SDK调用 # 这里的返回值仅用于演示流程 return 这是模型生成的初步结果。 def run_agent(task: str) - str: prompt f请完成以下任务{task} result call_llm(prompt) return result if __name__ __main__: output run_agent(帮我整理一份项目周报) print(output)这段代码的问题很明显模型返回什么就交付什么。没有检查输出是否有周报结构没有判断内容是否完整也没有考虑要不要查资料。如果模型生成了一段“内容不足50字”的瞎写结果系统同样会原样返回。这就是典型的“执行型”Agent。5.2 示例2通过自我批评引入反思判断# 文件路径agent_with_reflection.py def call_llm(prompt: str) - str: # 实际项目中替换为具体模型SDK调用 return 这是模型生成的候选结果。 def critique_answer(task: str, answer: str) - str: critique_prompt f 任务{task} 模型生成结果{answer} 请从完整性、准确性、可执行性三个方面检查该结果。 如果结果合格请输出固定单词已通过。 如果不合格请列出具体问题并给出修改建议。 return call_llm(critique_prompt) def run_agent_with_reflection(task: str, max_rounds: int 2) - str: answer call_llm(f请完成任务{task}) for i in range(max_rounds): feedback critique_answer(task, answer) if 已通过 in feedback: print(f第 {i 1} 次评审通过) return answer print(f第 {i 1} 次评审需要修正) answer call_llm( f任务{task}\n上一版结果{answer}\n f评审意见{feedback}\n请根据意见修改并输出新版本。 ) return answer if __name__ __main__: final_output run_agent_with_reflection(写一段数据库连接配置说明) print(final_output)这段代码引入了“生成—评审—修正”的循环。系统不再直接交付一手结果而是先检查再输出。注意两个细节一是评审提示词要求输出固定信号“已通过”避免解析歧义二是限制了最大反思轮数防止死循环。这是判断力最轻量的工程实现。5.3 示例3用可验证的检查项落地结果判断# 文件路径evaluate_judgment.py from agent_with_reflection import run_agent_with_reflection def check_output(text: str, required: list) - dict: return { 是否包含必备要素: all(k in text for k in required), 文本长度: len(text), 推荐工具使用: 未定义 } def run_evaluation(task: str, required: list) - dict: output run_agent_with_reflection(task) result check_output(output, required) return { 任务: task, 输出: output, 规则检查结果: result, } if __name__ __main__: evaluation run_evaluation( task生成5条短视频推广文案每条不超过30字, required[短视频, 推广] ) print(evaluation)这段代码把判断拆成了两层第一层是模型完成的语义反思第二层是规则完成的确定性检查。规则能精确判断“是否包含必备要素”“文本长度是否达标”这些不需要模型猜测。实际项目中判断力通常都是“模型负责开放场景、规则负责确定性校验”的混合结构。5.4 运行方式与验证以上代码需要在main入口直接运行python agent_without_judgment.py python agent_with_reflection.py python evaluate_judgment.py运行前需要把call_llm替换为实际模型SDK或者先使用一个返回固定文本的mock函数验证流程。第一段代码会直接打印模型结果第二段会打印反思轮数并输出经过修正的最终结果第三段会输出规则检查结果。如果运行失败第一步不是改模型而是检查call_llm是否返回了预期数据结构。判断力相关代码的调试几乎都是围绕“输入输出格式约定”展开的。6. 把“判断力”设计成论文中的可衡量贡献6.1 不要只给场景要给评估指标写了一堆Agent功能的论文最容易犯的错误是“只有场景没有度量”。要让判断力成为可论证的贡献至少需要一组指标指标说明衡量方式工具误用率不需要调用工具时错误调用的比例统计测试任务中工具调用次数终态判断准确率系统决定交付时结果是否真的合格人工复核交付结果反思修正率自我评审发现错误并修正的比例对比首轮结果和最终结果人类干预率需要人工介入才能继续的比例统计人工触发次数平均响应成本增加判断层后模型调用次数变化统计token用量和调用轮数其中“工具误用率”和“终态判断准确率”最值得写进论文因为它们能直接证明“判断层”有没有起作用。6.2 设计消融实验和失败案例评审最认可的实验方式之一是“有判断层”和“无判断层”的消融对比。保留同样的模型和工具只移除判断层观察指标变化。如果去掉判断层后系统在某些边界任务上明显退化说明判断力是真正起作用的组件。失败案例同样重要。收集典型错误样本把判断层捕捉到的错误类型完整呈现比单纯汇报一个准确率更有说服力。审稿人不只想看到“判断力有效”更想看到“判断力在什么场景下失效”。7. 常见问题与排查思路问题现象可能原因排查方式解决方案加入反思后结果反而变差评审提示词过于模糊模型不断重写查看首轮结果与终审结果的差异让评审只做“问题清单”不直接要求大改反思循环停不下来“已通过”判定标准不稳定打印每一轮评审输出约定固定通过信号并设置最大轮数判断层把合格结果判为不合格检查项过于严格或指标定义不清抽样人工复核误判样本调整检查项阈值区分硬性指标和软性指标多智能体协作时互相循环没有终止协议和决策权重观察多智能体对话轨迹引入最终决策者明确达到某条件立即结束调用成本明显上升每轮都触发完整反思分维度统计模型调用量只对高风险任务启动反思增加置信度阈值生产环境无法解释判断依据没有记录决策日志检查trace日志是否包含判断理由建立结构化日志输出每个判断节点8. 工程最佳实践让判断力真正可落地8.1 判断分层模型负责理解规则负责兜底判断力工程实现的第一原则是分层。模型擅长处理开放语义比如“这段摘要是否完整反映了报告核心”规则擅长处理确定性约束比如“输出不能为空”“金额字段必须是数字”“不允许删除未备份的数据”。不要把所有判断都交给模型也不要用规则穷举一切。正确姿势是高风险的判断用规则强制约束开放性的判断让模型给出结论并用规则做二次校验。8.2 记录判断证据日志不仅是日志判断力系统最好的调试工具是结构化的决策日志。每个判断节点记录以下信息判断输入、判断结果、判断依据、耗时、模型版本。这样线上出现问题可以通过trace_id还原完整决策链路。如果只是把agent的输出打印出来对论文和线上排障都不够。至少要以JSON行格式记录决策证据方便统计分析和复盘。8.3 控制反思成本与响应延迟反思机制不是免费的。每次自我批评都要额外调用模型可能让响应时间翻倍。实际工程里可以考虑按任务风险分级高风险的写操作任务开启完整反思低风险的普通问答可以直接返回。另外反思不是轮数越多越好。超过两轮仍然无法通过大概率不是修改不够而是评审条件本身有歧义。此时应该终止把任务交给人工处理而不是让Agent无限自转。8.4 安全边界高风险场景不能靠模型自觉涉及删除、权限变更、资金操作、生产环境配置修改时判断力不能替代安全门禁。模型可以给出“建议执行”的判断但最终执行必须由规则或人工确认控制这是不可妥协的底线。好的判断力系统应该同时具备“敢于判断”和“知道哪些判断不该自己做”的能力。对超出权限边界的操作不是强行给一个答案而是清晰表达“需要人工确认”并停止执行。9. 结语智能体的下一道分水岭智能体赛道正在从“跑得通”走向“信得过”。论文被拒不是坏事它说明评价体系已经开始把判断力当作Agent研究的及格线。对开发者来说这反而是一个清晰的信号接下来拼的不是谁集成的工具多而是谁能让系统为自己的每一步决策负责。下一次投稿或交付前先让智能体回答一个问题你凭什么认为你完成对了如果系统答不上来那说明判断层还没有建好。把这个细节补上远比多接一个工具更值得。 AI智能体的判断力：Agent从能执行到会判断的关键
最近看到几篇围绕AI智能体Agent的科研论文投稿反馈题目各不相同被拒理由却指向同一个词判断力。论文里的Agent能规划任务、能调用工具、能跑完整流程模型版本也用到了当时的主流方案实验跑出来的结果并不差。可审稿人依然不买账问题恰恰出在Agent最核心的环节——它只证明了“能执行”没有证明“会判断”。这个现象不是个例。当前大量智能体项目正在经历同一道坎会用工具、能跑流程的系统越来越多但能回答“为什么要这样选”“结果是否可信”“什么时候应该停下来”的系统仍然稀缺。判断力才是智能体从玩具走向科研结论和生产系统的分水岭。这篇文章想把模糊的“判断力”拆开讲清楚它在Agent架构里的具体位置为什么评审会盯着它不放以及我们在工程和科研中怎么把判断力做成可验证的模块。读完你会理解一篇智能体论文被拒表面上败给了审稿人实际上败给了“系统缺少评估链”这一硬伤。1. 被拒的不是论文是一类缺少判断力的智能体架构1.1 从论文评审看“执行型Agent”的局限现在很多Agent相关论文重点都在“用大模型做规划、选工具、执行多步任务”。这类工作本身有价值它证明了LLM可以驱动复杂流程。但审稿人现在开始问一个更难的问题这一连串动作每一步都经过判断了吗如果Agent只是根据初始问题自动生成一串计划然后按计划调用工具最后把结果原样返回那它的行为本质上还是“把提示词工程延展成了多步脚本”。它和传统自动化脚本的区别只有一个计划是模型生成的。一旦计划错了、工具结果不可信、最终产出不符合目标系统本身没有检测能力也没有修正机制。论文评审的变化本质上是学术界在倒逼Agent从“流程自动化”走向“判断组织化”。你不仅要告诉读者系统做了什么还要告诉读者系统如何知道自己做得对。1.2 判断力智能体最容易忽略的第四要素常规Agent结构常被总结成模型、规划、工具、记忆四大要素。这四个要素解决的是“能做什么、怎么拆、用什么做、记不记得”但没有回答“做得对不对、该不该继续、结果能不能信”。判断力更像一个横切关注点需要嵌入到每一个环节里而不是单独做一块补丁。对科研论文而言少了判断力系统在评审眼里就成了“黑箱里的黑箱”用户输入和最终输出之间发生了什么主要由模型内在随机性决定工程上无法隔离、无法排查、无法复现。这也是被拒反馈里最扎心的地方不是你的模型不够强而是你的系统没有对自己的行为负责。2. 判断力在智能体架构中的真实位置2.1 一个类比优秀实习生和听话机器的区别把Agent想成刚入职的实习生。实习生能力强能写代码、查资料、出方案。但没有经验的实习生最容易出问题的地方往往不是干活不够快而是不知道什么时候该停下来问、什么时候该怀疑任务本身不合理、什么时候发现自己产出已经偏离目标。Agent也是一样的道理。一个只执行不判断的Agent就像从不提问的实习生它给出的答案可能是错的但它没有能力发现也没有意愿复核。所谓“判断力”正是让系统具备“自我怀疑”和“自我校验”的能力。2.2 六个关键判断节点在一个典型Agent任务中至少有六个节点需要判断力参与判断节点问题示例需求澄清用户请求是否足够明确用户说“优化一下报告”是否需要追问报告对象任务拆解拆成几步先后顺序如何先查数据还是先定结构工具选择是否真的需要调用工具直接回答即可还是必须查库结果校验工具返回是否符合预期返回为空、超时、字段缺失如何处理质量检查生成结果是否达标长度、格式、事实、引用是否满足需求终止判断继续迭代还是交付结果已通过检查还是需要人工介入每个节点都对应一类错误。如果一个Agent在这六个节点上都只依赖一次模型生成那它就不是在“判断”而是在“猜”。2.3 为什么流程编排不能替代判断现在很多低代码Agent平台比如Dify、Coze核心价值都是帮助开发者把节点编排起来。编排解决的是“流程确定性”判断解决的是“路径选择性”。可以这样理解流程编排是把一条从输入到输出的路径画出来判断力是让Agent在这条路径的交叉口具备“选择下一步”的能力。如果一个流程的所有转移都由人工预先写死那它本质还是传统工作流只是披了一层Agent的外壳。这也是为什么审稿人会格外关注判断力它决定了你做的到底是“一个可交互的流程图”还是一个“有自主决策能力的系统”。3. 评审为什么会揪住“判断力”不放3.1 可复现性判断过程必须是确定或可解释的科研论文的基本要求是别人可以复现。传统代码只要固定输入、固定参数就能得到一致输出。Agent却不同模型本身的温度参数、prompt微调、工具返回顺序都会影响判断结果。如果判断过程只是“让LLM自己决定”那换个模型版本、换次随机种子系统的表现可能完全不同。审稿人要的不是每次结果都一样而是“在这里判断判据是什么”。至少要把判断规则、模型版本、prompt版本固定下来并清楚交代哪些部分是可复现的、哪些部分有随机性。3.2 可观测性要有办法看到判断依据一个没有判断力的系统其实也很难排查。结果对了你不知道是哪个环节做对了结果错了你也不知道错在哪个判断节点。给Agent增加判断力不只是让系统更好用更是让系统“可观测”。每一轮决策都应该能输出依据为什么选择这个工具、为什么判定结果不合格、为什么决定终止任务。这些依据是调试的证据也是论文中的分析素材。3.3 可验证性判断力需要有自己的评测集判断力本身必须能被量化评估。比如构造100个测试任务其中60个明确不需要调用工具40个必须调用工具。一个合格的Agent应该能在这两类任务上做出正确选择。如果一个系统没有这种“判断力测试集”那“我引入了反思机制”就只能算一个功能描述而不是科研贡献。审稿人想看的是你在哪个维度上、用哪个指标、验证了判断力的提升。4. 构建判断力的四种主流技术方案4.1 显式规则与状态机稳定但笨拙最直接的判断方式是写规则。比如“数据库操作必须带WHERE条件”“输出文本长度不能超过N字”“工具返回为空时必须重试”。这些规则可以用状态机、策略模式或条件表达式实现。优点很突出透明、可控、可测试线上出问题能立刻定位。缺点也很明显开放场景覆盖不住。用户问题是不断变化的靠规则无法穷尽所有判断场景。所以规则适合做“安全兜底”不适合做“唯一判断来源”。4.2 模型自评与反思最常用的轻量手段Self-Critique是目前最流行的轻量判断方案。流程是先生成一版答案再让模型扮演评审人进行逐项检查最后根据评审意见修改答案。关键在于批评提示词的设计——不要问“你觉得对吗”而是要让模型按维度检查。比如要求它检查“是否回答了用户问题”“引用的数据是否有来源”“输出是否超过字数限制”。同时需要约定明确的通过信号比如让模型输出固定的“通过”字样否则容易出现模型自我感觉良好、循环修改停不下来的情况。这种方式的成本很低但稳定性有限。同一个模型既当选手又当裁判容易出现“自我偏好”所以更稳妥的做法是再叠加一个独立的判断模块。4.3 验证者模型让判断成为独立组件验证者模型Verifier的思路是把“判断”从“生成”中剥离出来。生成模型负责产出答案验证模型负责打分或判定。验证模型可以是一个训练好的分类器也可以是另外一个大模型从结构化维度输出结论。这种方式的好处是判断与执行解耦便于单独评测和调优。你可以先优化验证模型的准确率再反过来指导生成模型的迭代方向。缺点是需要额外投入训练数据或模型调用成本对个人开发者和中小团队来说门槛不低。4.4 多智能体协作把判断变成对话多智能体是当下热门方向设计思路是让多个Agent扮演不同角色比如“生成者”“批评者”“决策者”。通过多轮交流让不同视角互相校验从而提升判断质量。但要特别注意多智能体不等于有判断力。如果只是让多个LLM聊天没有明确的信息边界和决策规则系统很容易陷入“互相认同”或“无限循环”。要让协作真正产生判断力至少要满足三个条件分工清晰、信息有边界、终止有协议。5. 最小示例给Agent加上判断力层下面用一个最小Python示例演示“无判断Agent”到“有反思判断Agent”的演进。代码中使用占位函数call_llm表示模型调用实际运行时要换成具体模型SDK。5.1 示例1一个没有任何判断的执行Agent# 文件路径agent_without_judgment.py def call_llm(prompt: str) - str: # 实际项目中替换为具体模型SDK调用 # 这里的返回值仅用于演示流程 return 这是模型生成的初步结果。 def run_agent(task: str) - str: prompt f请完成以下任务{task} result call_llm(prompt) return result if __name__ __main__: output run_agent(帮我整理一份项目周报) print(output)这段代码的问题很明显模型返回什么就交付什么。没有检查输出是否有周报结构没有判断内容是否完整也没有考虑要不要查资料。如果模型生成了一段“内容不足50字”的瞎写结果系统同样会原样返回。这就是典型的“执行型”Agent。5.2 示例2通过自我批评引入反思判断# 文件路径agent_with_reflection.py def call_llm(prompt: str) - str: # 实际项目中替换为具体模型SDK调用 return 这是模型生成的候选结果。 def critique_answer(task: str, answer: str) - str: critique_prompt f 任务{task} 模型生成结果{answer} 请从完整性、准确性、可执行性三个方面检查该结果。 如果结果合格请输出固定单词已通过。 如果不合格请列出具体问题并给出修改建议。 return call_llm(critique_prompt) def run_agent_with_reflection(task: str, max_rounds: int 2) - str: answer call_llm(f请完成任务{task}) for i in range(max_rounds): feedback critique_answer(task, answer) if 已通过 in feedback: print(f第 {i 1} 次评审通过) return answer print(f第 {i 1} 次评审需要修正) answer call_llm( f任务{task}\n上一版结果{answer}\n f评审意见{feedback}\n请根据意见修改并输出新版本。 ) return answer if __name__ __main__: final_output run_agent_with_reflection(写一段数据库连接配置说明) print(final_output)这段代码引入了“生成—评审—修正”的循环。系统不再直接交付一手结果而是先检查再输出。注意两个细节一是评审提示词要求输出固定信号“已通过”避免解析歧义二是限制了最大反思轮数防止死循环。这是判断力最轻量的工程实现。5.3 示例3用可验证的检查项落地结果判断# 文件路径evaluate_judgment.py from agent_with_reflection import run_agent_with_reflection def check_output(text: str, required: list) - dict: return { 是否包含必备要素: all(k in text for k in required), 文本长度: len(text), 推荐工具使用: 未定义 } def run_evaluation(task: str, required: list) - dict: output run_agent_with_reflection(task) result check_output(output, required) return { 任务: task, 输出: output, 规则检查结果: result, } if __name__ __main__: evaluation run_evaluation( task生成5条短视频推广文案每条不超过30字, required[短视频, 推广] ) print(evaluation)这段代码把判断拆成了两层第一层是模型完成的语义反思第二层是规则完成的确定性检查。规则能精确判断“是否包含必备要素”“文本长度是否达标”这些不需要模型猜测。实际项目中判断力通常都是“模型负责开放场景、规则负责确定性校验”的混合结构。5.4 运行方式与验证以上代码需要在main入口直接运行python agent_without_judgment.py python agent_with_reflection.py python evaluate_judgment.py运行前需要把call_llm替换为实际模型SDK或者先使用一个返回固定文本的mock函数验证流程。第一段代码会直接打印模型结果第二段会打印反思轮数并输出经过修正的最终结果第三段会输出规则检查结果。如果运行失败第一步不是改模型而是检查call_llm是否返回了预期数据结构。判断力相关代码的调试几乎都是围绕“输入输出格式约定”展开的。6. 把“判断力”设计成论文中的可衡量贡献6.1 不要只给场景要给评估指标写了一堆Agent功能的论文最容易犯的错误是“只有场景没有度量”。要让判断力成为可论证的贡献至少需要一组指标指标说明衡量方式工具误用率不需要调用工具时错误调用的比例统计测试任务中工具调用次数终态判断准确率系统决定交付时结果是否真的合格人工复核交付结果反思修正率自我评审发现错误并修正的比例对比首轮结果和最终结果人类干预率需要人工介入才能继续的比例统计人工触发次数平均响应成本增加判断层后模型调用次数变化统计token用量和调用轮数其中“工具误用率”和“终态判断准确率”最值得写进论文因为它们能直接证明“判断层”有没有起作用。6.2 设计消融实验和失败案例评审最认可的实验方式之一是“有判断层”和“无判断层”的消融对比。保留同样的模型和工具只移除判断层观察指标变化。如果去掉判断层后系统在某些边界任务上明显退化说明判断力是真正起作用的组件。失败案例同样重要。收集典型错误样本把判断层捕捉到的错误类型完整呈现比单纯汇报一个准确率更有说服力。审稿人不只想看到“判断力有效”更想看到“判断力在什么场景下失效”。7. 常见问题与排查思路问题现象可能原因排查方式解决方案加入反思后结果反而变差评审提示词过于模糊模型不断重写查看首轮结果与终审结果的差异让评审只做“问题清单”不直接要求大改反思循环停不下来“已通过”判定标准不稳定打印每一轮评审输出约定固定通过信号并设置最大轮数判断层把合格结果判为不合格检查项过于严格或指标定义不清抽样人工复核误判样本调整检查项阈值区分硬性指标和软性指标多智能体协作时互相循环没有终止协议和决策权重观察多智能体对话轨迹引入最终决策者明确达到某条件立即结束调用成本明显上升每轮都触发完整反思分维度统计模型调用量只对高风险任务启动反思增加置信度阈值生产环境无法解释判断依据没有记录决策日志检查trace日志是否包含判断理由建立结构化日志输出每个判断节点8. 工程最佳实践让判断力真正可落地8.1 判断分层模型负责理解规则负责兜底判断力工程实现的第一原则是分层。模型擅长处理开放语义比如“这段摘要是否完整反映了报告核心”规则擅长处理确定性约束比如“输出不能为空”“金额字段必须是数字”“不允许删除未备份的数据”。不要把所有判断都交给模型也不要用规则穷举一切。正确姿势是高风险的判断用规则强制约束开放性的判断让模型给出结论并用规则做二次校验。8.2 记录判断证据日志不仅是日志判断力系统最好的调试工具是结构化的决策日志。每个判断节点记录以下信息判断输入、判断结果、判断依据、耗时、模型版本。这样线上出现问题可以通过trace_id还原完整决策链路。如果只是把agent的输出打印出来对论文和线上排障都不够。至少要以JSON行格式记录决策证据方便统计分析和复盘。8.3 控制反思成本与响应延迟反思机制不是免费的。每次自我批评都要额外调用模型可能让响应时间翻倍。实际工程里可以考虑按任务风险分级高风险的写操作任务开启完整反思低风险的普通问答可以直接返回。另外反思不是轮数越多越好。超过两轮仍然无法通过大概率不是修改不够而是评审条件本身有歧义。此时应该终止把任务交给人工处理而不是让Agent无限自转。8.4 安全边界高风险场景不能靠模型自觉涉及删除、权限变更、资金操作、生产环境配置修改时判断力不能替代安全门禁。模型可以给出“建议执行”的判断但最终执行必须由规则或人工确认控制这是不可妥协的底线。好的判断力系统应该同时具备“敢于判断”和“知道哪些判断不该自己做”的能力。对超出权限边界的操作不是强行给一个答案而是清晰表达“需要人工确认”并停止执行。9. 结语智能体的下一道分水岭智能体赛道正在从“跑得通”走向“信得过”。论文被拒不是坏事它说明评价体系已经开始把判断力当作Agent研究的及格线。对开发者来说这反而是一个清晰的信号接下来拼的不是谁集成的工具多而是谁能让系统为自己的每一步决策负责。下一次投稿或交付前先让智能体回答一个问题你凭什么认为你完成对了如果系统答不上来那说明判断层还没有建好。把这个细节补上远比多接一个工具更值得。