你用 Agent 写了一晚上代码，功能跑通了，逻辑看起来也没毛病。但你盯着那几百行代码的时候，心里其实有点没底：变量名取得到位吗？边界条件全处理了吗？是不是藏着一个只有半夜上线才会炸的 bug？
这件事的底层焦虑其实不是 Agent 不行，是你没法验证它到底行不行。大多数人会把 Agent 的输出扫一眼就过，或者最多让 LLM 再”看一下有没有问题”。坦白讲，这种级别的检查约等于没查。
agentic-eval 做的事就是把”扫一眼”升级成一套有结构的评估流水线。它的核心思路很简单：让 Agent 的输出先经过评估器打分，不合格就退回重写，直到达标为止。这听起来像 CI/CD 管线的测试环节，只不过测试的对象从代码变成了 Agent 的行为本身。
说真的，这篇文章不会给你列一堆概念。我想做的是把这套评估模式拆开，看看它的三个核心 Pattern 怎么运作、评估策略怎么选、以及在实际场景里它到底能解决什么问题。如果你正在搭一个需要稳定输出的 Agent 系统，这套模式可能会帮你省掉不少 debug 时间。
环境准备
agentic-eval 托管在 Smithery 平台上，作为 AI & ML 分类下的一个 Skill，目前有约两万次浏览、五十多次安装。别被”安装量不高”吓到，评估类 Skill 天然是小众刚需，它不是那种人人都需要的通用工具，而是给真正在搭 Agent 系统的人准备的。
获取方式有两种。最直接的是在 Smithery 平台搜索 agentic-eval，点击安装后它会被注入到你使用的 AI Coding 工具的 Skill 上下文中。另一种方式更灵活：把它的 SKILL.md 里的 Prompt 和代码片段直接复制到你的 Agent 系统配置里。我推荐后者，因为评估逻辑最终是要嵌到你的 Agent 编排流程里的，不是独立运行的。
# 验证 Skill 已加载（以 CodeBuddy 为例）
# 在对话中尝试触发评估模式
请使用 agentic-eval 的评估模式评估以下代码质量：
[你的代码片段]
适配的环境没有硬性要求。它本质是一套 Prompt 模板加 Python 代码脚手架，不依赖特定框架。你用 LangChain、CrewAI、AutoGen 还是自己搭的 Agent loop 都没问题，只要你的 Agent 能调 LLM 和解析 JSON，就能把这套评估逻辑接进去。
常见的卡点在 JSON 解析这一步。评估器返回的结构化 JSON 如果格式不规整，你的 json.loads() 就会炸。从文档来看，建议在评估 Prompt 里强调”只返回合法 JSON，别加解释”，再在代码里包一层 try/except 加 fallback 逻辑。这点小细节做到位了，整套流程的稳定性会好很多。
操作流程
agentic-eval 的运作逻辑围绕一个简洁的循环展开：
-
生成：Agent 完成初始任务产出第一版内容 -
评估：按预设标准对输出逐维度打分 -
批评：提取不达标维度的具体反馈 -
优化：根据反馈定向修改，回到生成环节
这个环的核心假设是，Agent 的第一次输出大概率不够好，但给它一个明确的评估标准和一到两轮迭代，效果会有明显提升。
Pattern 1“Basic Reflection”是最基础的形态。Agent 先完成任务，然后把输出交给同一个 LLM 按预设标准打分。通过的放行，不通过的根据反馈重写。关键是评估输出必须是结构化 JSON，每个维度标注 PASS 或 FAIL 并附反馈。用自然语言写评估结果，解析环节基本必翻车。
def reflect_and_refine(task: str, criteria: list[str], max_iterations: int = 3) -> str:
output = llm(f"Complete this task:\n{task}")
for i in range(max_iterations):
critique = llm(f"""
Evaluate this output against criteria: {criteria}
Output: {output}
Rate each: PASS/FAIL with feedback as JSON.
""")
critique_data = json.loads(critique)
if all(c["status"] == "PASS" for c in critique_data.values()):
return output
failed = {k: v["feedback"] for k, v in critique_data.items()
if v["status"] == "FAIL"}
output = llm(f"Improve to address: {failed}\nOriginal: {output}")
return output
Pattern 2“Evaluator-Optimizer”把生成和评估拆成两个独立组件。这个设计的价值在于职责分离：生成器专心出内容，评估器只做打分，优化器拿着评估结果定向修补。三个组件各司其职，不会出现”生成器在写代码时已经想着怎么给自己辩护”这种奇怪的耦合。
Pattern 3“Code-Specific Reflection”是专门针对代码生成的。它多了一步：评估器不仅打分，还会自动生成测试用例，然后在测试环境里真的跑一遍。只有测试全绿才算通过。这一步把”AI 说代码没问题”升级成了”机器验证代码没问题”，质控的确定性直接上了一个台阶。
三个 Pattern 从简到繁，但核心逻辑一致：用评估结果驱动迭代，而不是靠更聪明的 Prompt 一次到位。这个设计哲学在整个 Skill 里贯彻得很彻底。
关键设计
agentic-eval 做对了一件很多 Agent 框架没做好的事：它把评估标准抬到了和生成 Prompt 同等重要的位置。大多数人在搭 Agent 时，90% 的精力花在写”怎么做”的 Prompt 上，”怎么判断做得好不好”基本靠感觉。这套 Skill 的设计起点恰恰反过来了：先定义什么样的输出算合格，再让生成器往那个方向靠。
三条评估策略的选型也值得细看。Outcome-Based 直接对比实际输出和预期结果，适合有明确正确答案的任务。LLM-as-Judge 让一个 LLM 当裁判比较两个输出，适合没有标准答案但”哪个更好”可以主观判断的场景。Rubric-Based 是加权打分，把质量拆成多个维度分别评估再加权汇总，适合需要平衡多个质量标准的情况。
RUBRIC = {
"accuracy": {"weight": 0.4},
"clarity": {"weight": 0.3},
"completeness": {"weight": 0.3}
}
三条策略可以叠加使用。比如代码生成场景，先用 Rubric 评估结构和可读性，再用 Outcome-Based 验证功能正确性，两者不互斥。
但有一个设计上的坑不能不提：LLM-as-Judge 的可靠性高度依赖 Judge 模型本身的能力。如果你用一个偏弱的模型做评估，它给出的 PASS/FAIL 判断本身可能就是有问题的。这种情况下，迭代循环不仅不会改善输出，反而可能把一个还不错的版本改坏。从架构推断，设计者显然意识到了这一点，所以加了 max_iterations 和 convergence check 两道安全阀。不过这两道阀本质上是在限制”改坏”的幅度，而不是解决 Judge 模型能力不足的根本问题。
使用场景
代码生成是这套评估模式最自然的应用场景。你让 Agent 写一个函数，评估器自动生成测试用例跑一遍，不通过就打回重写。Pattern 3 的 Code-Specific Reflection 就是为这件事设计的。本质上，它把 TDD 的循环从「人写测试、人写代码」变成了：
-
Agent 写代码 -
Agent 写测试 -
机器跑验证
三步各自独立，质控链不依赖人的判断。
报告和文档生成是另一个很适合的场景，但这里更适合用 Pattern 1 或 2。给评估器一份 Rubric：结构清晰度、数据准确性、语言简洁度各占一定权重。Agent 生成初稿后评估器打分，得分低于 0.8 就重写。但要注意，文字质量的主观性比代码正确性高得多，Rubric 的维度设计和权重分配会直接影响最终效果。
不适合的场景也很明确。如果你的任务本身就缺少清晰的评判标准，比如让 Agent 做创意文案、头脑风暴或者开放式研究分析，强行套评估模式只会得到一个机械打分的循环，既浪费 Token 也没产出更好的内容。另外，实时性要求高的交互场景也不适用，每轮评估加迭代多出来的几秒延迟，用户体验直接崩掉。
这套模式对比其他 Agent 质量保障方案，比如 Anthropic 的系统 Prompt 分层设计或 OpenAI 的 Structured Outputs，解决的是不同层面的问题。后者控制的是”输出格式正确”，agentic-eval 控制的是”输出内容正确”。一个管格式，一个管质量，两种方案叠加使用效果最好。
洞察与反思
agentic-eval 真正有价值的地方不在代码层面，在它确立了一种设计范式：把质量保障从”前置预防”转向”后置检测”。传统思路是拼命优化 Prompt，塞更多指令、加更详细的示例，试图让 Agent 一次就生成完美输出。这条路走不通的原因很简单：你没法在 Prompt 里穷举所有可能的错误类型。
后置检测的思路更务实。承认第一次输出不够好，但确保有机制能发现它不够好、并有路径让它变好。这个逻辑转变在工程上的意义，比三个 Pattern 的具体实现要大得多。它意味着你在设计 Agent 系统时，可以接受生成器不那么完美，只要评估器足够可靠就行。
但这件事也有一个很容易被忽略的前提：评估标准本身的质量。如果你的评估标准定得不好，或者 Judge 模型的能力跟不上，整个迭代循环就是一个精致的错误放大器。从社区反馈来看，目前最可靠的策略是把 Rubric-Based 和 Outcome-Based 组合使用，让主观评估和客观验证互相制衡，而不是赌某一条路。
我个人觉得，未来半年到一年，评估器会成为 Agent 系统的标配组件。就像 CI/CD 管线里测试环节从”最好有”变成了”必须有”一样，Agent 输出质量也会走过同样的路。agentic-eval 的定位不是”完美的评估框架”，而是”评估这件事的起点”。它给的三个 Pattern 和三条策略足够清晰，留的扩展空间也足够大。如果你想在这个方向上走得更远，一个好的起点是把 Pattern 2 的 Evaluator 组件换成更强的基础模型，或者引入多 Judge 投票机制来降低单点偏差。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery | https://smithery.ai/skills/github/agentic-eval |
总结
回到开头那个问题：Agent 写的代码你敢直接上线吗？agentic-eval 给出的答案不是”敢”，而是”先让它自己跑一遍测试”。
这套评估模式的价值在于，它把 Agent 的输出质量从玄学问题变成了工程问题。你可以量化它、测试它、迭代它，而不是对着一个黑盒输出凭感觉判断。三个 Pattern 覆盖了从简单打分到测试驱动的完整梯度，三条评估策略让你可以根据场景灵活组合。
我写这篇文章的过程中，最大的感受是：Agent 系统的成熟度正在从”能不能做事”转向”做的事靠不靠谱”。评估不是锦上添花，是下一个阶段的基础设施。如果你正在让 Agent 做的事越来越重要，把评估器搭起来这件事，别再等了。