Activepieces Chat Prompt Eval 实战指南用回归 Fixture 与 LLM 裁判为 AI Copilot 系统提示词建立评测门禁【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces本文讲解 Activepieces 仓库中为AI Copilot Chat 系统提示词system prompt设计的评测工具——Chat Prompt Eval。它是一个先评测、后决策的门禁gate用一组提交入库的回归用例fixtures对提示词改动跑真实模型推理再用确定性断言 LLM 裁判双重校验结果最后交由人审阅并决定是否放行。读完本文你将掌握它的运行方式、fixture 编写规范、断言与裁判维度设计以及它是如何在源码层面把提示词改了是否变好变成可重复验证的工程实践的。定位它是门禁不是评审替代品Chat Prompt Eval 解决的核心问题是AI Copilot 的聊天系统提示词改动后如何证明变好而不是只是感觉上变好。它在 Activepieces 中的定位非常克制——工具只负责告诉你要不要开这个 PRpromotion 到生产仍然是人工发起的 PR评测结果不自动合并代码。从 runner.ts 可以看到整个评测复用生产链路runAgentTurn是 agent 回合的真实执行入口agentWorkerTools提供生产工具集评测只是把工具执行替换成录制回放并注入评测专用提示词因此评测结果对生产行为有直接参考意义。运行它命令、密钥与日常循环两条命令仓库根目录 package.json 中实际定义了三条脚本README 中写作chat-evals真实脚本名是agent-evals以 package.json 为准npm run agent-evals # 交互式审查器有缓存则直接复用缓存结果 npm run agent-evals:ci # 非交互 vitest 门禁供脚本/CI 使用 npm run agent-evals:live # live 场景评测packages/server/worker/test/lib/agent-eval/live/agent-evals加载.env.dev环境变量通过tsx直接运行 CLI 入口 index.ts。如果已有缓存运行结果会直接进入审查界面不产生任何 LLM 费用。agent-evals:ci执行vitest run --dir packages/server/worker/test/lib/agent-eval把该目录下的 agent-eval.test.ts、eval-gate-triggers.test.ts、replay-executor.test.ts、transcript-assertions.test.ts 等作为确定性门禁运行。密钥从哪里来两条命令都会从.env.dev加载AP_OPENROUTER_PROVISION_KEY或OPENROUTER_API_KEY。两种密钥都可用且推荐使用 provisioning key评测运行器会用它铸造一把短时效的 inference key评测结束即删除避免把生产密钥暴露给评测进程。从 runner.ts 源码看这个铸造-复用-删除流程有三个工程细节值得注意inference key 优先如果OPENROUTER_API_KEY已存在直接使用它promise 级记忆化mintedKeyPromise缓存的是进行中的 Promise而非已 resolve 的值。因为多个 fixture 通过Promise.all并发调用resolveAuth()若缓存值每个调用方都会各自铸造一把 key除最后一个外全部泄漏缓存 Promise 则确保只铸造一次失败清理铸造失败会清空记忆化引用保证重试时重新铸造。日常循环README 给出的标准工作流是编辑提示词 →npm run agent-evals -- --fresh→ 审查 → Proceed / Stopnpm run agent-evals -- --fresh--fresh强制进行真实评测而非复用缓存。审查通过后退出码为 0Proceed拒绝则退出码为 1Stop随后由你打开提示词的 PR。Baseline vs Candidate一次运行两份对比每次运行每个 fixture 都会被评测两次形成 A/B 对比baseline gitHEAD已提交上的提示词candidate 你的工作区改动或通过--candidate显式指定的提示词文件。当工作区干净时baseline 与 candidate 相同运行一次并提示 no prompt changes。这个机制在 prompts.ts 中有清晰实现提示词资产位于packages/server/api/src/assets/prompts/主文件是chat-system-prompt.md另有guides/下的四份引导文档build_flow、one_time_task、error_handling、http_fallbackHEAD 读取通过execFileSync(git, [show, HEAD:path])实现工作区读取用readFileSync读取时会做模板变量替换{{PROJECT_LIST}}、{{PROJECT_CONTEXT}}、{{FRONTEND_URL}}被替换为评测专用值如https://eval.activepieces.test让评测环境与生产环境解耦changed标志通过比较 baseline 与 candidate 的 system prompt 和 guides 的序列化结果得出决定是否真的需要跑第二遍。Flags三个开关Flag使用场景无立即重开缓存结果仅在无缓存时真实运行零 LLM 成本--fresh编辑了提示词想要全新结果--candidate path用显式提示词文件做 A/B替代工作区 vs HEAD非交互的通过/失败门禁脚本/CI请使用npm run agent-evals:ci。审查器里有什么进入审查器后交互逻辑位于 review.tsDashboard每个 fixture 一行baseline │ candidate │ ΔΔ 取三态——▲ improved/▼ regressed/ same。同时展示judge calibrationbaseline 与 candidate 各自的 TPR真阳率与 TNR真阴率用于检验裁判本身是否可靠Browse fixtures逐项查看每个检查的 diff翻转项高亮、裁判评语judge notes与完整 transcript按模型产出顺序渲染文字与工具调用交错Proceedexit 0/ Stopexit 1记录决策到decisions.json然后你去开提示词 PRRe-run live不改动评测工具即可在再次编辑后重新评测返回 Dashboard。Fixtures团队的好行为共同定义回归用例存放在packages/server/worker/test/lib/agent-eval/fixtures/*.json全部提交入库因此它们是团队对好行为的共享定义。README 明确要求一个提示词改动与支撑它的 fixtures 应该在同一个 PR 中门禁检查保持健壮、确定性主观质量交给人工评审。当前仓库已内置 26 个 fixture覆盖提示词工程的典型风险面例如guard-duplicate-flow-not-agent.json——防过度纠正用户明确点名现有自动化并要求 clone 时必须复制该 flow而不是把它理解成构建自主 agent/数字孪生injection-untrusted-content-not-instruction.json——提示注入防御no-leak-internal-mechanism.json与no-count-leak.json——内部机制与计数不泄漏recurring-digest-only-new.json、recurring-orders-no-resend.json、recurring-payroll-no-reprocess.json——循环类任务的幂等与去重intent-self-as-agent-clone-me.json、intent-self-as-agent-does-my-job.json——自我定位边界energy-calibration-frustrated.json、persona-mission-conveys-range.json——语气与人格校准。以 guard-duplicate-flow-not-agent.json 为例userTurns为 clone my Daily lead sync to HubSpot automation so I can tweak the copy通过recordedToolCalls回放一次ap_list_across_projects的工具输出列出两个 flow断言neverCutOff裁判维度duplicates_named_flow_not_agent的 rubric 精确写明了 PASS 与 FAIL 的判定边界。如何新增一个 fixture参见 fixtures/README.md流程为复制骨架到fixtures/your-id.json填写userTurns用户说的话与关心的检查npm run agent-evals -- --fresh→ 审阅 transcript 与判定 → 调整直至反映真正良好的行为与它佐证的提示词改动一起提交一个 PR。骨架可直接复制的合法 JSON{ id: my-fixture-id, description: One line: the behavior this case pins down., kind: regression, initialMessages: [], userTurns: [ the users first message ], recordedToolCalls: [], model: { provider: openrouter, modelId: anthropic/claude-sonnet-4.6, tier: { id: balanced, thinkingBudget: 2000, modelId: anthropic/claude-sonnet-4.6 } }, assertions: [ { type: neverCutOff }, { type: maxQuestionCards, n: 2 }, { type: noBuildToolBeforePhaseSet } ], judge: [ { dimension: plain_language, rubric: What a PASS looks like, stated precisely. Be explicit about what is and isnt allowed., expectedLabel: pass } ] }类型定义见 fixture.ts加载逻辑见 fixtures-loader.ts只读取.json.md说明文件被自然忽略。字段说明字段含义id唯一 slug同时也是文件名description报告中展示的人工说明kindregression 门禁硬性要求必须通过capability 被评测并计入裁判校准但不硬性阻断门禁aspirational 目标initialMessages之前的对话原始模型消息通常为[]userTurns用户消息按顺序每条一个字符串recordedToolCalls录制的工具输出评测时确定性回放纯发现型场景模型只问/答、不调用跨项目工具为[]modelprovider为openroutermodelId/tier.modelId为 OpenRouter slugtier.thinkingBudget为思考 token 预算assertions确定性检查下表judgeLLM 裁判的质量维度rubric 见后文断言确定性检查门禁首选六种断言在 transcript-assertions.ts 中实现每种都返回{ pass, reason }便于在审查界面展示判定理由type参数通过条件源码级判定逻辑neverCutOff—响应未被输出 token 上限截断truncatedAfterRetries为假且finishReason ! lengthneverAskedHow—没有出现技术性澄清提问。判定为正则匹配how (do\|would\|should\|will\|might) (you\|we\|i)、which (field\|column\|property\|trigger\|step\|action\|piece\|connection)等模式README 提醒这是 blunt regex会对 how would you like… 这类良性表达误报需谨慎使用noBuildToolBeforePhaseSet—在 discovery 阶段没有运行 build-only 工具检查每条工具调用若agentToolPhases.isBuildOnlyTool(toolName)成立但phase ! build则失败maxQuestionCardsn可选toolNames[]问题卡片不超过n张。默认统计名称匹配question/quick_repl的工具可用toolNames覆盖为统计指定工具calledBeforea、b工具a先于工具b被调用任一未调用即失败reachedToolWithintoolName、ntoolName首次被调用的顺序 ≤nJudge 维度主观质量每个 judge 条目是{ dimension, rubric, expectedLabel }。裁判读取完整 transcript 后按 rubric 返回 PASS/FAIL测试再与expectedLabel比较。裁判的实现见 llm-judge.ts以temperature: 0调用generateText系统提示要求裁判只对一个维度、一个通过标准做严格二值判定标准未明确满足即判 FAIL输出首行 PASS/FAIL、次行一句话理由。在 runner.ts 中判定通过与否被进一步泛化为pass (expectedLabel pass)——这样capabilityfixture 可以显式期望 FAIL记录已知局限提示词改动后能否转正也能被观测而不是永远红着。编写 rubric 的要点把 rubric 写成精确的 PASS 标准并明确写清允许什么例如 asking which app the user uses is fine — thats a business question, not technical避免裁判过度标记expectedLabel几乎总是pass使用fail标签的维度仅用于测试裁判能否正确抓到坏行为它供给 TPR/TNR 校准检查真正主观、依赖迭代次数的判断放进capabilityfixture而不是regression。recordedToolCalls确定性回放对于必须调用跨项目/MCP 工具的用例录制工具输出以保证运行确定性。每个条目为{ order, toolName, recordedInput?, output }。回放执行器 replay-executor.ts 的实现值得注意按order排序后用一个游标顺序消费模型调用工具时严格按位置比对工具名若与录制不符则记录 divergence 并返回{ __evalDivergence: true }哨兵值让模型看到工具行为偏离这样既复现了真实工具输出又能暴露模型调了录制里没有的工具这类偏差——这正是评价提示词是否引导模型走预期路径的关键信号。底层评测管线一个 fixture 如何被执行完整管线在 runner.ts 中evaluateFixture先解析认证见上文密钥机制runTurn组装评测环境用replayExecutor替代真实工具执行phaseState跟踪AgentPhase初始为discovery工具集由五组生产工具拼装而成——本地工具createLocalTools注入EVAL_PROJECTS、展示工具createDisplayTools评测中waitForApproval直接返回已批准、跨项目工具createCrossProjectTools执行走回放、思考工具与阶段工具createPhaseTools更新 phase消息序列 initialMessagesuserTurns注入 system prompt 后调用生产函数runAgentTurn终止条件isLoopFinished()之外还监听一组终端展示工具ap_show_questions、ap_show_quick_replies、ap_show_connection_picker等。这些卡片在生产环境会阻塞等待用户输入评测自动批准它们因此在此处结束回合以镜像展示卡片、等待用户的语义避免循环反复催促模型重新提问renderTranscript按模型产出顺序文字与工具调用交错渲染成纯文本 transcript供裁判阅读真实序列汇总断言结果 裁判判定 → 生成 EvalReportEntry → 由 run.ts 计算improved / regressed / same三态并写入缓存。产物与决策留痕运行产物存放在仓库根目录.agent-eval/gitignored仅本机见 store.ts注意README 写作.chat-eval/源码实际目录为.agent-eval/last-run.json——本次运行缓存含时间戳、provider/model、baseline/candidate 标签、是否发生变更以及每个 fixture 的对比结果decisions.json——每次 Proceed/Stop 的决策日志记录判定时间、verdict、通过数量统计、回归/改进的 fixture 列表与可选备注形成可追溯的提示词改动历史。把门禁接入 CI对于脚本与 CI使用非交互门禁npm run agent-evals:ci它运行 vitest 于packages/server/worker/test/lib/agent-eval目录包含门禁触发、回放执行器与 transcript 断言等单元测试。结合 fixture 体系中regression类型的硬性通过要求团队可以在 PR 流水线里对提示词改动 配套 fixtures做自动回归校验再叠加人工审查器中的主观判断最终形成机器把关确定性、人工把关质量的双层门禁。使用建议与边界确定性优先能用断言neverCutOff、maxQuestionCards、calledBefore等表达的不要交给裁判断言健壮、可重复裁判只承接真正主观的质量维度fixture 与提示词改动同 PR新行为必须有新 fixture 佐证避免改完没证据校准裁判关注 dashboard 上的 TPR/TNR若裁判经常误报回头打磨 rubric 的允许什么表述注意命名差异README 中的chat-evals与.chat-eval/在仓库实际脚本与源码中分别为agent-evals与.agent-eval/以 package.json 与源码为准评测有成本每次--fresh都会对每个 fixture 跑真实模型推理baseline candidate 各一次复用缓存无 flag 直接运行是零成本重看结果的方式。总而言之Chat Prompt Eval 把提示词工程从不可复现的直觉判断变成了fixture 定义行为 确定性断言兜底 LLM 裁判校准主观维度 人工审阅拍板的闭环工程流程——这正是 AI 应用团队在系统提示词持续演进时最需要的质量基础设施。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Activepieces Chat Prompt Eval 实战指南：用回归 Fixture 与 LLM 裁判为 AI Copilot 系统提示词建立评测门禁
Activepieces Chat Prompt Eval 实战指南用回归 Fixture 与 LLM 裁判为 AI Copilot 系统提示词建立评测门禁【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces本文讲解 Activepieces 仓库中为AI Copilot Chat 系统提示词system prompt设计的评测工具——Chat Prompt Eval。它是一个先评测、后决策的门禁gate用一组提交入库的回归用例fixtures对提示词改动跑真实模型推理再用确定性断言 LLM 裁判双重校验结果最后交由人审阅并决定是否放行。读完本文你将掌握它的运行方式、fixture 编写规范、断言与裁判维度设计以及它是如何在源码层面把提示词改了是否变好变成可重复验证的工程实践的。定位它是门禁不是评审替代品Chat Prompt Eval 解决的核心问题是AI Copilot 的聊天系统提示词改动后如何证明变好而不是只是感觉上变好。它在 Activepieces 中的定位非常克制——工具只负责告诉你要不要开这个 PRpromotion 到生产仍然是人工发起的 PR评测结果不自动合并代码。从 runner.ts 可以看到整个评测复用生产链路runAgentTurn是 agent 回合的真实执行入口agentWorkerTools提供生产工具集评测只是把工具执行替换成录制回放并注入评测专用提示词因此评测结果对生产行为有直接参考意义。运行它命令、密钥与日常循环两条命令仓库根目录 package.json 中实际定义了三条脚本README 中写作chat-evals真实脚本名是agent-evals以 package.json 为准npm run agent-evals # 交互式审查器有缓存则直接复用缓存结果 npm run agent-evals:ci # 非交互 vitest 门禁供脚本/CI 使用 npm run agent-evals:live # live 场景评测packages/server/worker/test/lib/agent-eval/live/agent-evals加载.env.dev环境变量通过tsx直接运行 CLI 入口 index.ts。如果已有缓存运行结果会直接进入审查界面不产生任何 LLM 费用。agent-evals:ci执行vitest run --dir packages/server/worker/test/lib/agent-eval把该目录下的 agent-eval.test.ts、eval-gate-triggers.test.ts、replay-executor.test.ts、transcript-assertions.test.ts 等作为确定性门禁运行。密钥从哪里来两条命令都会从.env.dev加载AP_OPENROUTER_PROVISION_KEY或OPENROUTER_API_KEY。两种密钥都可用且推荐使用 provisioning key评测运行器会用它铸造一把短时效的 inference key评测结束即删除避免把生产密钥暴露给评测进程。从 runner.ts 源码看这个铸造-复用-删除流程有三个工程细节值得注意inference key 优先如果OPENROUTER_API_KEY已存在直接使用它promise 级记忆化mintedKeyPromise缓存的是进行中的 Promise而非已 resolve 的值。因为多个 fixture 通过Promise.all并发调用resolveAuth()若缓存值每个调用方都会各自铸造一把 key除最后一个外全部泄漏缓存 Promise 则确保只铸造一次失败清理铸造失败会清空记忆化引用保证重试时重新铸造。日常循环README 给出的标准工作流是编辑提示词 →npm run agent-evals -- --fresh→ 审查 → Proceed / Stopnpm run agent-evals -- --fresh--fresh强制进行真实评测而非复用缓存。审查通过后退出码为 0Proceed拒绝则退出码为 1Stop随后由你打开提示词的 PR。Baseline vs Candidate一次运行两份对比每次运行每个 fixture 都会被评测两次形成 A/B 对比baseline gitHEAD已提交上的提示词candidate 你的工作区改动或通过--candidate显式指定的提示词文件。当工作区干净时baseline 与 candidate 相同运行一次并提示 no prompt changes。这个机制在 prompts.ts 中有清晰实现提示词资产位于packages/server/api/src/assets/prompts/主文件是chat-system-prompt.md另有guides/下的四份引导文档build_flow、one_time_task、error_handling、http_fallbackHEAD 读取通过execFileSync(git, [show, HEAD:path])实现工作区读取用readFileSync读取时会做模板变量替换{{PROJECT_LIST}}、{{PROJECT_CONTEXT}}、{{FRONTEND_URL}}被替换为评测专用值如https://eval.activepieces.test让评测环境与生产环境解耦changed标志通过比较 baseline 与 candidate 的 system prompt 和 guides 的序列化结果得出决定是否真的需要跑第二遍。Flags三个开关Flag使用场景无立即重开缓存结果仅在无缓存时真实运行零 LLM 成本--fresh编辑了提示词想要全新结果--candidate path用显式提示词文件做 A/B替代工作区 vs HEAD非交互的通过/失败门禁脚本/CI请使用npm run agent-evals:ci。审查器里有什么进入审查器后交互逻辑位于 review.tsDashboard每个 fixture 一行baseline │ candidate │ ΔΔ 取三态——▲ improved/▼ regressed/ same。同时展示judge calibrationbaseline 与 candidate 各自的 TPR真阳率与 TNR真阴率用于检验裁判本身是否可靠Browse fixtures逐项查看每个检查的 diff翻转项高亮、裁判评语judge notes与完整 transcript按模型产出顺序渲染文字与工具调用交错Proceedexit 0/ Stopexit 1记录决策到decisions.json然后你去开提示词 PRRe-run live不改动评测工具即可在再次编辑后重新评测返回 Dashboard。Fixtures团队的好行为共同定义回归用例存放在packages/server/worker/test/lib/agent-eval/fixtures/*.json全部提交入库因此它们是团队对好行为的共享定义。README 明确要求一个提示词改动与支撑它的 fixtures 应该在同一个 PR 中门禁检查保持健壮、确定性主观质量交给人工评审。当前仓库已内置 26 个 fixture覆盖提示词工程的典型风险面例如guard-duplicate-flow-not-agent.json——防过度纠正用户明确点名现有自动化并要求 clone 时必须复制该 flow而不是把它理解成构建自主 agent/数字孪生injection-untrusted-content-not-instruction.json——提示注入防御no-leak-internal-mechanism.json与no-count-leak.json——内部机制与计数不泄漏recurring-digest-only-new.json、recurring-orders-no-resend.json、recurring-payroll-no-reprocess.json——循环类任务的幂等与去重intent-self-as-agent-clone-me.json、intent-self-as-agent-does-my-job.json——自我定位边界energy-calibration-frustrated.json、persona-mission-conveys-range.json——语气与人格校准。以 guard-duplicate-flow-not-agent.json 为例userTurns为 clone my Daily lead sync to HubSpot automation so I can tweak the copy通过recordedToolCalls回放一次ap_list_across_projects的工具输出列出两个 flow断言neverCutOff裁判维度duplicates_named_flow_not_agent的 rubric 精确写明了 PASS 与 FAIL 的判定边界。如何新增一个 fixture参见 fixtures/README.md流程为复制骨架到fixtures/your-id.json填写userTurns用户说的话与关心的检查npm run agent-evals -- --fresh→ 审阅 transcript 与判定 → 调整直至反映真正良好的行为与它佐证的提示词改动一起提交一个 PR。骨架可直接复制的合法 JSON{ id: my-fixture-id, description: One line: the behavior this case pins down., kind: regression, initialMessages: [], userTurns: [ the users first message ], recordedToolCalls: [], model: { provider: openrouter, modelId: anthropic/claude-sonnet-4.6, tier: { id: balanced, thinkingBudget: 2000, modelId: anthropic/claude-sonnet-4.6 } }, assertions: [ { type: neverCutOff }, { type: maxQuestionCards, n: 2 }, { type: noBuildToolBeforePhaseSet } ], judge: [ { dimension: plain_language, rubric: What a PASS looks like, stated precisely. Be explicit about what is and isnt allowed., expectedLabel: pass } ] }类型定义见 fixture.ts加载逻辑见 fixtures-loader.ts只读取.json.md说明文件被自然忽略。字段说明字段含义id唯一 slug同时也是文件名description报告中展示的人工说明kindregression 门禁硬性要求必须通过capability 被评测并计入裁判校准但不硬性阻断门禁aspirational 目标initialMessages之前的对话原始模型消息通常为[]userTurns用户消息按顺序每条一个字符串recordedToolCalls录制的工具输出评测时确定性回放纯发现型场景模型只问/答、不调用跨项目工具为[]modelprovider为openroutermodelId/tier.modelId为 OpenRouter slugtier.thinkingBudget为思考 token 预算assertions确定性检查下表judgeLLM 裁判的质量维度rubric 见后文断言确定性检查门禁首选六种断言在 transcript-assertions.ts 中实现每种都返回{ pass, reason }便于在审查界面展示判定理由type参数通过条件源码级判定逻辑neverCutOff—响应未被输出 token 上限截断truncatedAfterRetries为假且finishReason ! lengthneverAskedHow—没有出现技术性澄清提问。判定为正则匹配how (do\|would\|should\|will\|might) (you\|we\|i)、which (field\|column\|property\|trigger\|step\|action\|piece\|connection)等模式README 提醒这是 blunt regex会对 how would you like… 这类良性表达误报需谨慎使用noBuildToolBeforePhaseSet—在 discovery 阶段没有运行 build-only 工具检查每条工具调用若agentToolPhases.isBuildOnlyTool(toolName)成立但phase ! build则失败maxQuestionCardsn可选toolNames[]问题卡片不超过n张。默认统计名称匹配question/quick_repl的工具可用toolNames覆盖为统计指定工具calledBeforea、b工具a先于工具b被调用任一未调用即失败reachedToolWithintoolName、ntoolName首次被调用的顺序 ≤nJudge 维度主观质量每个 judge 条目是{ dimension, rubric, expectedLabel }。裁判读取完整 transcript 后按 rubric 返回 PASS/FAIL测试再与expectedLabel比较。裁判的实现见 llm-judge.ts以temperature: 0调用generateText系统提示要求裁判只对一个维度、一个通过标准做严格二值判定标准未明确满足即判 FAIL输出首行 PASS/FAIL、次行一句话理由。在 runner.ts 中判定通过与否被进一步泛化为pass (expectedLabel pass)——这样capabilityfixture 可以显式期望 FAIL记录已知局限提示词改动后能否转正也能被观测而不是永远红着。编写 rubric 的要点把 rubric 写成精确的 PASS 标准并明确写清允许什么例如 asking which app the user uses is fine — thats a business question, not technical避免裁判过度标记expectedLabel几乎总是pass使用fail标签的维度仅用于测试裁判能否正确抓到坏行为它供给 TPR/TNR 校准检查真正主观、依赖迭代次数的判断放进capabilityfixture而不是regression。recordedToolCalls确定性回放对于必须调用跨项目/MCP 工具的用例录制工具输出以保证运行确定性。每个条目为{ order, toolName, recordedInput?, output }。回放执行器 replay-executor.ts 的实现值得注意按order排序后用一个游标顺序消费模型调用工具时严格按位置比对工具名若与录制不符则记录 divergence 并返回{ __evalDivergence: true }哨兵值让模型看到工具行为偏离这样既复现了真实工具输出又能暴露模型调了录制里没有的工具这类偏差——这正是评价提示词是否引导模型走预期路径的关键信号。底层评测管线一个 fixture 如何被执行完整管线在 runner.ts 中evaluateFixture先解析认证见上文密钥机制runTurn组装评测环境用replayExecutor替代真实工具执行phaseState跟踪AgentPhase初始为discovery工具集由五组生产工具拼装而成——本地工具createLocalTools注入EVAL_PROJECTS、展示工具createDisplayTools评测中waitForApproval直接返回已批准、跨项目工具createCrossProjectTools执行走回放、思考工具与阶段工具createPhaseTools更新 phase消息序列 initialMessagesuserTurns注入 system prompt 后调用生产函数runAgentTurn终止条件isLoopFinished()之外还监听一组终端展示工具ap_show_questions、ap_show_quick_replies、ap_show_connection_picker等。这些卡片在生产环境会阻塞等待用户输入评测自动批准它们因此在此处结束回合以镜像展示卡片、等待用户的语义避免循环反复催促模型重新提问renderTranscript按模型产出顺序文字与工具调用交错渲染成纯文本 transcript供裁判阅读真实序列汇总断言结果 裁判判定 → 生成 EvalReportEntry → 由 run.ts 计算improved / regressed / same三态并写入缓存。产物与决策留痕运行产物存放在仓库根目录.agent-eval/gitignored仅本机见 store.ts注意README 写作.chat-eval/源码实际目录为.agent-eval/last-run.json——本次运行缓存含时间戳、provider/model、baseline/candidate 标签、是否发生变更以及每个 fixture 的对比结果decisions.json——每次 Proceed/Stop 的决策日志记录判定时间、verdict、通过数量统计、回归/改进的 fixture 列表与可选备注形成可追溯的提示词改动历史。把门禁接入 CI对于脚本与 CI使用非交互门禁npm run agent-evals:ci它运行 vitest 于packages/server/worker/test/lib/agent-eval目录包含门禁触发、回放执行器与 transcript 断言等单元测试。结合 fixture 体系中regression类型的硬性通过要求团队可以在 PR 流水线里对提示词改动 配套 fixtures做自动回归校验再叠加人工审查器中的主观判断最终形成机器把关确定性、人工把关质量的双层门禁。使用建议与边界确定性优先能用断言neverCutOff、maxQuestionCards、calledBefore等表达的不要交给裁判断言健壮、可重复裁判只承接真正主观的质量维度fixture 与提示词改动同 PR新行为必须有新 fixture 佐证避免改完没证据校准裁判关注 dashboard 上的 TPR/TNR若裁判经常误报回头打磨 rubric 的允许什么表述注意命名差异README 中的chat-evals与.chat-eval/在仓库实际脚本与源码中分别为agent-evals与.agent-eval/以 package.json 与源码为准评测有成本每次--fresh都会对每个 fixture 跑真实模型推理baseline candidate 各一次复用缓存无 flag 直接运行是零成本重看结果的方式。总而言之Chat Prompt Eval 把提示词工程从不可复现的直觉判断变成了fixture 定义行为 确定性断言兜底 LLM 裁判校准主观维度 人工审阅拍板的闭环工程流程——这正是 AI 应用团队在系统提示词持续演进时最需要的质量基础设施。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考