PostHog 離線評測實(shí)戰(zhàn)基于 MCP 的 Markdown 筆記本 Agent 評測體系搭建指南【免費(fèi)下載鏈接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.項目地址: https://gitcode.com/GitHub_Trending/po/posthog導(dǎo)讀本文基于倉庫內(nèi)products/notebooks/plan/notebooks_mcp_evals_plan.md這份評測規(guī)劃文檔系統(tǒng)講解 PostHog 如何為「基于 MCP 工具創(chuàng)建與編輯 Markdown 筆記本」的 AI Agent 建立離線評測offline evals體系。你將理解評測基建eval harness如何與 MCP server、Temporal、kernel 沙箱協(xié)同工作如何設(shè)計創(chuàng)建型與編輯型評測用例eval cases如何用「工具軌跡 → 數(shù)據(jù)庫終態(tài) → LLM 裁判」三層評分棧衡量 Agent 行為以及如何編寫 seeder 與 synthesizer 讓評測數(shù)據(jù)可復(fù)現(xiàn)。文中的目錄與代碼均已按當(dāng)前倉庫實(shí)際實(shí)現(xiàn)核對可對照閱讀。1. 評測體系的底座獨(dú)立 eval harness 與兩種套件類型PostHog 的 Agent 離線評測并不運(yùn)行在 pytest 之上而是由一個獨(dú)立的評測框架承載——位于 products/posthog_ai/eval_harness/ 的 standalone harness。其運(yùn)作方式是hogli evals一次性啟動共享基礎(chǔ)設(shè)施測試數(shù)據(jù)庫、Django live server、LLM gateway、MCP server、Temporal、personhog然后并發(fā)運(yùn)行所有被選中的套件以 Braintrust 作為評測引擎。套件分兩種類型由模塊級常量SUITE_KIND聲明見 harness/requirements.py套件類型聲明方式每個用例的執(zhí)行方式啟動的基礎(chǔ)設(shè)施sandboxed默認(rèn)不聲明或SUITE_KIND SuiteKind.SANDBOXED真實(shí)編碼 Agent 在真實(shí)沙箱中驅(qū)動 MCP server全部基礎(chǔ)設(shè)施one-shotSUITE_KIND SuiteKind.ONE_SHOT一次進(jìn)程內(nèi)模型調(diào)用測試數(shù)據(jù)庫、personhog、demo 數(shù)據(jù)Notebook MCP 評測屬于 sandboxed 類型被測對象是「驅(qū)動真實(shí)工具、操作真實(shí)狀態(tài)的 Agent」一次性的單次調(diào)用根本無法覆蓋這種行為。這也是整個評測設(shè)計的出發(fā)點(diǎn)。圍繞這套體系規(guī)劃文檔強(qiáng)調(diào)了幾條塑造設(shè)計的關(guān)鍵事實(shí)均已在實(shí)際代碼中得到印證按約定發(fā)現(xiàn)套件無注冊表產(chǎn)品自有套件放在products/product/evals/注意是復(fù)數(shù)evals/單數(shù)products/signals/eval/是無關(guān)的 pytest 樹套件 ID 格式為product/module::fn導(dǎo)入路徑為products.product.evals.module。本評測的目錄即為products/notebooks/evals/。一個套件 一個 Braintrust experimentexperiment_name是歷史鍵history key改名等于重置跨輪次對比。現(xiàn)有套件統(tǒng)一保留-cli后綴以對齊歷史上 MCP 的cli表面。每個用例擁有獨(dú)立組織/團(tuán)隊/用戶每個 case 都會從一個 master Hedgebox 團(tuán)隊克隆出自己的 org/team/user用例之間永遠(yuǎn)看不到彼此的狀態(tài)預(yù)置用戶名為 Karen Smith。Hedgebox 數(shù)據(jù)集在固定種子下可字節(jié)級復(fù)現(xiàn)因此評測斷言應(yīng)檢查形狀和相對日期范圍絕不要斷言絕對計數(shù)。case 字段name、prompt、expected按 scorer 的_name()鍵控、metadata、setup即 seeder。seeder 的返回值會進(jìn)入output[seed]這是 scorer 獲取預(yù)置 ID 的唯一通道。harness 會給每個 experiment 自動添加ExitCodeZeroscorer見 scorers/deterministic.py套件自身不得重復(fù)聲明否則會被拒絕。沙箱評測不進(jìn) CI.github/workflows/ci-ai.yml只運(yùn)行較舊的ee/hogai/eval/cipytest 樹且需要evals-readylabel本評測按需在本地或 Modal 上運(yùn)行。想了解 harness 內(nèi)部運(yùn)行細(xì)節(jié)可閱讀 eval_harness/README.md 與 harness/README.md。2. 被測表面revamped-py-notebooks旗標(biāo)下的工具集Notebook 評測的目標(biāo)表面是 MCP 中的 notebook 工具集合。在revamped-py-notebooks功能旗標(biāo)開啟后注冊的是以下工具h(yuǎn)and-written 為手寫工具generated 為從 OpenAPI schema 腳手架生成工具類型說明notebooks-create-markdownhand-written標(biāo)題 可選正文明確拒絕攜帶 cellsnotebooks-add-cellhand-writtensql/python/markdown/saved_insight/componentsql 與 python 會派發(fā)運(yùn)行并把結(jié)果寫回文檔notebooks-update-cellhand-written編輯代碼并重跑或省略 code 原樣重跑返回stale_dependentsnotebooks-delete-cellhand-written—notebook-edithand-writtenMarkdown 字符串替換old_markdown/new_markdown/replace_allnotebooks-getgenerated標(biāo)題、markdown、cells、depends_on/dependents、派生的 stale 狀態(tài)notebooks-list-frames、notebooks-configure-compute、notebooks-run-cell-result、notebooks-run-cell-interruptgeneratedkernel 側(cè)工具的定義與描述可以在 products/notebooks/mcp/tools.yaml 中直接查看——例如notebooks-get被標(biāo)記為feature_flag: revamped-py-notebooks而notebooks-create采用feature_flag_behavior: disable且superseded_by: notebooks-create-markdown說明新舊兩套工具是互斥關(guān)系。旗標(biāo)關(guān)閉時注冊的是舊版工具集notebooks-create、notebooks-retrieve、notebooks-partial-update而所有 markdown 工具直接消失。兩套工具集互斥這一點(diǎn)直接影響下文 harness 的改造方式。3. 已驗(yàn)證的環(huán)境阻塞點(diǎn)讓評測跑通的關(guān)鍵改造規(guī)劃文檔列出了讓 Notebook 評測真正可運(yùn)行的五個阻塞點(diǎn)及其解決方案其中大部分已經(jīng)在 harness 中落地a. Markdown 工具通過旗標(biāo)覆寫到達(dá)評測 MCP server。工具過濾tool filtering以revamped-py-notebooks門控整個 markdown 工具集測試見 services/mcp/tests/unit/tool-filtering.test.ts而評測 MCP server 在FEATURE_FLAG_OVERRIDES中設(shè)置該旗標(biāo)。實(shí)測代碼位于 harness/services.py其覆寫字典為{revamped-py-notebooks: True, ...}。副作用是它同時把notebooks-create/notebooks-retrieve從評測工具列表中移除因此若想評測舊版 notebook 工具需要另一種杠桿見第 9 節(jié)「開放決策」。b. Django 側(cè)的門控已經(jīng)滿足。harness/lifecycle.py 會 patchposthoganalytics.feature_enabled使其在整個運(yùn)行期間返回True因此受旗標(biāo)門控的 SQLV2 端點(diǎn)可以正常應(yīng)答。c. 兩條 cell 運(yùn)行通道目前僅 docker 可用。純 HogQL 運(yùn)行走直連通道direct laneenqueue_direct_run位于 backend/presentation/views/notebook.py掛載在異步查詢管理器上。harness 以TEST1運(yùn)行此時 Celery 是 eager 模式查詢內(nèi)聯(lián)執(zhí)行不涉及沙箱。Python 與 DuckDB 運(yùn)行調(diào)用start_sql_v2_run_workflow需要 notebook 的 Temporal 工作流已注冊、且存在 kernel 沙箱。harness 現(xiàn)在兩者都做到了詳見 eval_harness/README.md#notebook-kernel-sandboxes在這項改造之前運(yùn)行會一直停留在running狀態(tài)直到輪詢窗口過期。kernel 通道僅 dockernotebook kernel 直接從SANDBOX_PROVIDER讀取后端而 modal provider 將其設(shè)為MODAL_EVALS這不是KernelRuntime.Backend的合法值。因此python/duckdb 用例必須用--provider docker運(yùn)行純 SQL 用例兩種 provider 均可。d. Scope 沒有問題。沙箱上下文默認(rèn)為fullMCP scopes見 custom_prompt_internals.py其中已包含notebook:write。e. 終態(tài)評分可行但必須異步。Braintrust 基類的_run_eval_async會在事件循環(huán)上直接調(diào)用_run_eval_sync因此任何在 scorer 里做同步 ORM 操作的行為都會觸發(fā) Django 的異步安全守衛(wèi)。讀取數(shù)據(jù)庫的 scorer 應(yīng)繼承AsyncOnlyScorerMixin, Scorer見 scorers/contract.py并把數(shù)據(jù)庫工作放進(jìn)asyncio.to_thread。倉庫中已有先例DuplicateUniqueFlagKey位于 products/posthog_ai/evals/experiments/scorers.py。前提是 seeder 必須返回team_id否則終態(tài)評分無從談起。4. 用例選型用 MCP 分析數(shù)據(jù)錨定「會回歸的行為」用例選擇的原則是從工具實(shí)際行為出發(fā)而非追求覆蓋面上的面面俱到。規(guī)劃文檔建議在選型前先用 MCP 分析工具查看 notebook 工具的真實(shí)使用數(shù)據(jù)query-mcp-tool-stats與query-mcp-tool-failures或 MCP analytics UI。規(guī)劃撰寫時的觀測結(jié)果很有參考價值notebook-edit在所有編輯工具中錯誤率最高且多數(shù)失敗是晦澀的internal錯誤——遙測中拋出的Error的表現(xiàn)形態(tài)通常意味著old_markdown未找到或不唯一。這是最高價值的目標(biāo)也是唯一具有真實(shí)失敗簽名可復(fù)現(xiàn)的用例。notebooks-add-cell使用量尚小評測在這里是「在大規(guī)模使用前鎖定行為」而非救火。舊版notebooks-partial-update主要失敗在 HTTP 409 版本沖突。值得長期堅持的選型原則每個可合理回歸的行為一個用例而非每個工具一個用例。優(yōu)先選擇「錯誤答案易檢測、且在生產(chǎn)中代價高昂」的用例例如覆蓋clobber文檔、丟失 cell 結(jié)果、重建已存在的 insight。至少包含一個「正確行為是不調(diào)用任何工具」的用例以及一個「工具拒絕首次嘗試、Agent 必須恢復(fù)」的用例——這兩類能捕捉純成功用例漏掉的 prompt 回歸。已落地的 Suite 0eval_notebook_cells通道檢查規(guī)劃文檔中標(biāo)記為「已發(fā)布」的套件實(shí)際實(shí)現(xiàn)見 products/notebooks/evals/eval_notebook_cells.py。它包含三個用例python_cell_arithmetic最便宜的 kernel 通道冒煙測試無查詢、無 dataframe、無 cell 間依賴。若它通過而其他用例失敗說明沙箱沒問題、是 Agent 的分析壞了。sql_cell_report證明直連通道——要求創(chuàng)建名為 Signup momentum 的 notebook、用 SQL cell 返回最近 8 周signed_up事件的周計數(shù)并加一段 markdown 摘要。expected中的cell_runs_completed.node_types為[hogql]。python_cell_from_dataframe端到端證明 kernel 通道——先加 SQL cell 取周計數(shù)再加 Python cell 讀取該 cell 的 dataframe 計算周環(huán)比變化。node_types為[hogql, python]兩條通道都覆蓋。值得注意的評分設(shè)計CellRunsCompleted評的是NotebookNodeRun行而非對話記錄因?yàn)椤敢雅砂l(fā)的運(yùn)行」和「已完成的運(yùn)行」在日志里看起來幾乎一樣——工具調(diào)用返回的要么是status: running要么是已完成。只有 run 行才是 notebook 真正渲染內(nèi)容的誠實(shí)來源。完整 scorer 實(shí)現(xiàn)見 products/notebooks/evals/scorers.py。提案套件 Aeval_notebook_authoring從分析請求創(chuàng)建用例Prompt 形態(tài)評分要點(diǎn)create_signup_reportCreate a notebook called X showing weeklysigned_upcounts over the last 8 weeks, with a short summary使用notebooks-create-markdown添加一個完成的 SQL cell命名標(biāo)題添加 prosemulti_cell_dependency兩個相關(guān) SQL 步驟后者讀取前者的 dataframedataframe 命名、refs、依賴順序embed_saved_insightPut our Weekly signups insight in a notebook通過saved_insightcell 復(fù)用預(yù)置 insight而不是重寫 SQLcomponent_hogql_rejected誘導(dǎo) Agent 使用 HogQL source 的componentcell工具拒絕該嘗試Agent 恢復(fù)為cell_type: sql提案套件 Beval_notebook_editing修改既有 notebook 且不破壞它用例Prompt 形態(tài)評分要點(diǎn)local_prose_editReword the intro section of notebook X只編輯目標(biāo)片段其余每個 section 與兩個 cell 的runId/result原樣保留insert_cell_afterAdd a breakdown cell right after the signups cell使用after_node_id而非在末尾追加delete_one_cellDrop the file-size cell恰好刪除一個 cellrefresh_stale_cells預(yù)置了一個上游 cell 已變更的 notebook讀取notebooks-get用notebooks-update-cell且不帶code按依賴順序重跑 stale cells八個 sandboxed 用例是合理的第一批規(guī)模每個用例都是一次完整的 Agent 運(yùn)行成本線性增長20 個用例的套件會變得難以迭代。5. 數(shù)據(jù)生成synthesizer 與 seeder 的分工Hedgebox 提供事件、insights、dashboards 和 flags但不提供 notebooks。因此編輯類和定向類用例需要 seeder 來預(yù)置數(shù)據(jù)。規(guī)劃文檔建議沿用data_warehouse的 synthesizer/seeder 分工倉庫當(dāng)前目錄products/notebooks/evals/已按此結(jié)構(gòu)落地products/notebooks/evals/ __init__.py constants.py # 共享字面量標(biāo)題、錨點(diǎn)、node id、dataframe 名 synthesizer.py # 純確定性 markdown 文檔構(gòu)建器 seeders.py # 把數(shù)據(jù)安裝進(jìn)每個用例的團(tuán)隊ORM[已發(fā)布] scorers.py # 軌跡 終態(tài) 裁判評分器 [已發(fā)布] eval_notebook_cells.py # 兩條運(yùn)行通道 [已發(fā)布] eval_notebook_authoring.py eval_notebook_editing.pysynthesizer.py純 Python、不依賴 Django、確定性。把 markdown 文檔構(gòu)建為 frozen dataclasssection 錨點(diǎn)、固定nodeId的 cell 標(biāo)簽、dataframe 名以及用例必須找到的預(yù)置「needle」。單元測試應(yīng)放在products/notebooks/backend/test/絕不放進(jìn)evals/樹內(nèi)。以其中的build_churn_needle為例默認(rèn)種植 6 個賬戶count6oldest_active_day120、newest_active_day70、session_stride_days4——即賬戶在 120 天前注冊、持續(xù)活躍到 70 天前、此后完全沉默形成教科書式的流失形狀。所有標(biāo)識符distinct_id、account_key、email、name都攜帶CHURN_TOKEN hollowbrook標(biāo)記。seeders.py接收CustomPromptSandboxContext在用例自己的團(tuán)隊里創(chuàng)建Notebook行內(nèi)容等價于buildMarkdownNotebookContent(markdown)對 staleness 用例還會創(chuàng)建NotebookNodeRun行讓notebooks-get報出真實(shí)的運(yùn)行狀態(tài)。constants.py被 prompt、expected載荷和 scorer 共享的所有字面量標(biāo)題、錨點(diǎn)字符串、node ID、dataframe 名集中存放這是防止 prompt 與 scorer 漂移的關(guān)鍵機(jī)制。Seeder 契約中容易踩坑的細(xì)節(jié)務(wù)必遵守同步函數(shù)def seed_x(context) - dict[str, Any]。harness 通過asyncio.to_thread調(diào)用它見 base.py永遠(yuǎn)不要把它寫成 async。沒有每用例參數(shù)用例特有的狀態(tài)意味著要寫專用的 seeder 函數(shù)而不是給共享 seeder 加開關(guān)。返回 scorer 需要的一切包括team_id和 notebookshort_id編輯類用例還要返回markdown_before供 scorer 做 diff。seeder 拋異常 基礎(chǔ)設(shè)施錯誤該用例會被排除在平均值之外破損的 seeder 永遠(yuǎn)不會被誤讀為 Agent 回歸。對 authoring 套件而言seeder 是可選的Hedgebox 已經(jīng)自帶了embed_saved_insight需要的 Weekly signups insight。但一個只返回{team_id: ...}的最小 seeder 仍然值得寫——它能解鎖終態(tài)評分seeders.py 中的seed_case_team正是如此。6. 三層評分棧軌跡 → 終態(tài) → 裁判評分采用三層結(jié)構(gòu)確定性層作為主干僅在問題真正屬于定性判斷時才動用 LLM 裁判。第一層工具軌跡來自 Agent 日志確定性Scorer子類讀取LogParser.cached(output[raw_log], ...)解析器見 log_parser.py。優(yōu)先復(fù)用通用評分器RequiredToolCall、NoToolCall、LastToolCallNot、CalledTargetTool來自 cli_mcp/scorers.py 等通用集。notebook 特有新增UsedMarkdownNotebookFlow—— 通過notebooks-create-markdown創(chuàng)建而非手拼文檔。CellsTitled—— 每個成功的 sql/pythonadd-cell都攜帶非空title工具描述強(qiáng)制要求PR #75471 正是因 Agent 跳過它而存在。ReusedSavedInsight—— 使用帶預(yù)置 short_id 的saved_insightcell且沒有重復(fù)相同查詢的 SQL cell。RanCellsInDependencyOrder—— 對更新鏈每次上游重跑都先于其依賴者的重跑。RecoveredFromToolRejection—— 先嘗試被拒絕的形態(tài)、隨后正確調(diào)用成功是對RecoveredToCorrectTool的泛化。第二層終態(tài)來自數(shù)據(jù)庫—— 本倉庫的新增層這一層才能真正捕獲生產(chǎn)故障也是本倉庫評測體系的新增部分。異步 scorerAsyncOnlyScorerMixin, Scorerasyncio.to_thread使用seed[team_id]和seed[notebook_short_id]從 Postgres 讀回 notebookNotebookIsMarkdown—— content 仍是單個ph-markdown-notebook節(jié)點(diǎn)沒有被覆蓋成舊版富文本。PreservedUnrelatedContent——seed[markdown_before]中除編輯目標(biāo)外的每個錨點(diǎn)仍然存在每個既有 cell 標(biāo)簽仍攜帶其nodeId、runId、resultprops。這是覆蓋故障的直接反制。CellRunSucceeded—— 新增 cell 的NotebookNodeRun行處于DONE且 envelope 非空。用于捕獲「寫了一個看起來對、實(shí)際報錯的 cell」。system.notebooks也通過 HogQL 暴露markdown列但 scorer 直接讀 ORM 更簡單還能省去一次查詢往返。第三層LLM 裁判質(zhì)量層JudgedScorer子類基類見 scorers/judged.py只需實(shí)現(xiàn)_prepareNotebookAnswersQuestion—— 給定最終 markdownnotebook 是否真正回答了 prompt正確的指標(biāo)、正確的時間窗口、有圖表、有可快速瀏覽的 prose。CellTitlesAreDescriptive—— 標(biāo)題說明 cell 展示的內(nèi)容而不是「這是 SQL」。裁判從同一次數(shù)據(jù)庫讀取中拿到最終 markdown因此天然是異步的。倉庫中已落地的定性裁判NotebookApproachQuality同文件 scorers.py展示了完整形態(tài)從工具調(diào)用記錄中讀取 Agent 撰寫的 cells而非數(shù)據(jù)庫用NOTEBOOK_APPROACH_PROMPTNOTEBOOK_APPROACH_RUBRIC六檔量表perfect → useless讓裁判按預(yù)期 approach 打分。評分紀(jì)律scoreNone表示「此檢查不適用于此用例」會從聚合中剔除0.0表示 Agent 做錯了且同樣覆蓋「裁判損壞」與「輸入缺失」這類不能無聲消失的路徑。只統(tǒng)計成功的工具調(diào)用is_errorFalse——Agent 被允許嘗試并失敗。每個 scorer 只實(shí)現(xiàn)一個分支_run_eval_sync與_run_eval_async二選一絕不雙實(shí)現(xiàn)。expected載荷按 scorer 名稱鍵控這樣一份 scorer 列表就能覆蓋整個套件。7. 目錄布局與套件骨架評測樹內(nèi)不允許出現(xiàn)conftest.py或pytest導(dǎo)入synthesizer 的單元測試放在products/notebooks/backend/test/。這一約定與 pytest 默認(rèn)只收集test_*.py的規(guī)則天然契合——eval_*.py不會被誤收集。套件骨架取自規(guī)劃文檔與實(shí)際實(shí)現(xiàn)一致from products.posthog_ai.eval_harness.base import SandboxedPublicEval from products.posthog_ai.eval_harness.config import SandboxedEvalCase from products.posthog_ai.eval_harness.harness.context import EvalContext async def eval_notebook_editing(ctx: EvalContext) - None: await SandboxedPublicEval( experiment_namesandboxed-notebooks-editing-cli, cases[...], scorers[...], ctxctx, )默認(rèn)使用SandboxedPublicEval除非某個 prompt 或 seed 不應(yīng)離開本機(jī)public 形態(tài)會獲得 Braintrust URL 和跨運(yùn)行歷史。SandboxedPublicEval/SandboxedPrivateEval的實(shí)現(xiàn)是SandboxedEval的兩個偏函數(shù)見 base.py前者is_publicTrue, no_send_logsFalse會同時向 Braintrust 與 PostHog 上報后者反之只寫本地日志。保留-cli后綴讓命名與其余 MCP 套件對齊。8. 上線順序與運(yùn)行命令規(guī)劃文檔給出了明確的推進(jìn)次序前兩步已完成落地在評測 MCP server 中啟用revamped-py-notebooks注冊 notebook Temporal 工作流回收 kernel 沙箱。已完成eval_notebook_cells就是證明這條鏈路通暢的用例。添加eval_notebook_authoring——先用軌跡評分器覆蓋判別性用例復(fù)用 saved insight、從 componentHogQL 拒絕中恢復(fù)。添加文檔 seeder 與PreservedUnrelatedContent然后是eval_notebook_editing。裁判最后加——它們是最嘈雜的一層也最容易過擬合。穩(wěn)定后用--trials 3運(yùn)行觀察方差后再把任何分?jǐn)?shù)當(dāng)作基線。常用命令需在 flox shell 中運(yùn)行hogli evals --list | grep notebooks # 確認(rèn)發(fā)現(xiàn)import 檢查模塊 hogli evals eval_notebook_cells --eval python_cell_from_dataframe --provider docker hogli evals notebooks --provider docker # 整個域docker 是因?yàn)?kernel 通道更完整的 harness 參數(shù)可從 eval_harness/README.md 查閱常用的包括--eval substr只跑名稱含子串的用例、--provider {docker,modal}默認(rèn) docker、--max-sandboxes N并發(fā)沙箱上限docker 默認(rèn) 4、--trials N每用例跑 N 次、--fail-under fraction均值低于閾值則非零退出等。運(yùn)行結(jié)束后的排查要點(diǎn)讀取最后一行打印的 transcript 路徑然后查看 experiment agent-log 目錄下的每用例case.jsonl與case.summary.txt——光看分?jǐn)?shù)無法告訴你用例為什么失敗原始 Agent 日志才是最快的定位途徑。9. 開放決策與已知邊界Kernel 通道的 modal 支持目前僅 docker這使 python cell 用例并發(fā)被限制在四個沙箱左右。要解除限制需要讓 notebook kernel 認(rèn)識MODAL_EVALS為 modal 后端——這是為評測而改生產(chǎn)代碼只有當(dāng) python 套件規(guī)模超出 docker 承載能力時才值得。舊版 notebook 工具啟用旗標(biāo)會隱藏它們因此任何針對notebooks-create/notebooks-partial-update409 沖突路徑有真實(shí)錯誤量的評測需要「每套件」的旗標(biāo)杠桿而不是進(jìn)程級環(huán)境變量。裁判模型成本裁判按「每個用例 × 每個 scorer」計費(fèi)。八個用例配兩個裁判沒問題十個裁判就太多了。附從規(guī)劃到已落地的代碼對照規(guī)劃文檔寫作時標(biāo)注為「已發(fā)布」shipped的部分在倉庫中均可找到實(shí)現(xiàn)套件入口products/notebooks/evals/eval_notebook_cells.py三條用例experiment_namesandboxed-notebook-cells-cli另一已落地的開放分析套件 products/notebooks/evals/eval_notebook_analysis.py 用seed_churn_signal預(yù)置流失賬戶群并用ChurnCohortSurfaced按「筆記本 prose 中點(diǎn)名了預(yù)置賬戶的占比」打分。評分器products/notebooks/evals/scorers.pyNotebookCreated、CellRunsCompleted、ChurnCohortSurfaced、NotebookApproachQuality。Seederproducts/notebooks/evals/seeders.pyseed_case_team、seed_churn_signal含 ClickHouse 事件種植與 persons 數(shù)據(jù)庫鏡像。合成器products/notebooks/evals/synthesizer.py確定性 churn needle 構(gòu)建。工具定義products/notebooks/mcp/tools.yamlmarkdown 工具集與舊工具集的旗標(biāo)互斥關(guān)系。評測基建harness 的 MCP 服務(wù)裝配與 kernel 沙箱支持見 eval_harness/harness/services.py 與 eval_harness/harness/kernel_sandboxes.py。這套評測體系的最終目的是用可復(fù)現(xiàn)、可并發(fā)、可跨運(yùn)行對比的方式把「Agent 會不會用 notebook 工具、用得對不對、結(jié)果是否真的落到了數(shù)據(jù)庫」變成一組可以被長期盯防的分?jǐn)?shù)——在生產(chǎn)功能上線之前就把回歸擋在門外。【免費(fèi)下載鏈接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.項目地址: https://gitcode.com/GitHub_Trending/po/posthog創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考