人工智能AI Agent多智能体Agent 工作流深度研究AI 评测【免费下载链接】PRAXISTAutonomous research system for measurable, computer-executable research.项目地址https://gitcode.com/gh_mirrors/pr/PRAXIST点击查看免费下载本文以 docs/guides/budget-policies.md 为骨架结合 PRAXIST 仓库内praxist/core与praxist/plugins/budget_policies的源码实现展开。PRAXIST 的预算是动态的它不是一次性拷贝进某次运行、之后对所有实验盲目强制的固定元组而是由 Agent 与工作流阶段在运行时按单位提出请求由可插拔的 BudgetPolicy 插件给出 grant / downscope / require_review / deny 四种决策再由账本ledger与执行守卫execution guard持续记录、核算与强制。读完本文你将掌握 PRAXIST 预算请求的字段与单位规范、默认策略default_basic的判定规则、usage_unknown的语义与落地实现以及预算策略的测试与重放校验方法。一、预算在 PRAXIST 中为什么是动态的docs/guides/budget-policies.md开门见山地定义了 PRAXIST 预算治理的第一原则Budget is dynamic in Praxist. It is not a fixed tuple copied once into a run and then blindly enforced for every experiment.翻译成实现语言这意味着预算不是运行前写死的常量而是贯穿运行生命周期的一组运行时交互Agent 与工作流阶段发起请求 → 策略插件决策 → 账本记录 → 执行守卫在关键动作上按授予额度核算。源码中这条链路由以下模块分工praxist/core/protocol.py定义BudgetRequest、BudgetGrant、BudgetDecision三种可序列化数据结构praxist/core/budget.py提供单位校验与策略注册表分发policy_for_refpraxist/core/ledgers.pyBudgetLedger负责把请求、决策、用量、用量未知四种记录写入运行目录的 JSONL 账本praxist/core/execution_guards.pyBudgetedActionGuard在每个高成本动作runtime、tool、GPU、evaluation上记录实际用量praxist/core/replay.py在重放校验阶段验证账本内 grant 与 usage / usage_unknown 记录的引用完整性。动态性的直接好处是一个「便宜探针」cheap probe实验可以被策略自动放行而一个「强证据大额实验」既能拿到完整额度也可能被降档downscope甚至被路由给 Chair 规划 Agent 人工审查——同一套运行逻辑在不同场景下得到不同、但可解释的预算待遇。二、预算请求Budget Requests单位、字段与语义2.1 请求单位Budget UnitsAgent 与工作流阶段可以按当前核心校验器core validator接受的单位提出预算请求原文档列出的三种核心单位是单位unit含义典型用途tokens模型调用消耗的 token 数限制 LLM 推理开销wall_clock_seconds墙上时钟秒数限制实验挂墙时长gpu_hoursGPU 使用小时数限制 GPU 计算开销在源码层面praxist/core/budget.py 给出了权威定义INFORMATIONAL_USAGE_UNITS frozenset({cost_usd, neurons}) ALLOWED_BUDGET_UNITS {tokens, wall_clock_seconds, gpu_hours} | set( INFORMATIONAL_USAGE_UNITS )这里有一个值得注意的细节除了文档明示的三种治理单位代码还允许cost_usd与neurons两种信息型单位informational units。从 praxist/core/ledgers.py 的get_exhausted_units可以看到它们的特殊地位for unit, raw_amount in approved.items(): if unit in INFORMATIONAL_USAGE_UNITS: continue # recorded for reporting; never gates execution也就是说cost_usd/neurons只用于上报与报告从不参与执行门槛判定真正能「卡住」运行的是tokens、wall_clock_seconds、gpu_hours三个治理单位。这正是「信息型记录」与「治理型限制」分离的设计。2.2 请求应包含的内容原文档要求请求应包含scope范围、reason理由、estimated cost预估成本、expected value预期价值、以及会消耗预算的动作action。在代码中这些被映射为 praxist/core/protocol.py 的BudgetRequest冻结数据类字段dataclass(frozenTrue) class BudgetRequest: request_id: str requester_id: str experiment_id: str model_profile_ref: str | None requested: dict[str, float] expected_value: dict[str, JSONValue] evidence_refs: list[str] cheaper_alternatives: list[str] abort_conditions: list[str]字段与文档要求的对应关系scope / reason / action体现在requester_id谁发起、experiment_id哪个实验、request_id请求唯一标识以及调用方传入的action_type在账本记录阶段写入estimated costrequested: dict[str, float]即按 2.1 节单位给出的预估消耗expected valueexpected_value: dict[str, JSONValue]这是策略判定最重要的输入之一——default_basic会读取其中的confidencestrong/ 其他与impossible标志见下文证据链evidence_refs列出支撑该请求的证据引用如finding:acceptedcheaper_alternatives提供更廉价的替代方案abort_conditions声明什么条件下应中止。BudgetRequest是frozen数据类因此天然可哈希、可序列化便于写入账本与重放比对——重放一致性正是预算治理正确性的前提。三、策略决策Policy Decisions四种出口与默认姿态3.1 策略可执行的决策集合原文档列出BudgetPolicy可做的四类事自动放行低风险请求、降档请求、把异常大的请求交给 PI 或 Chair 规划 Agent 审查、拒绝会损害运行或超出操作员限制的请求。对应到 praxist/core/protocol.py 的BudgetDecision决策通过decision字符串表达dataclass(frozenTrue) class BudgetDecision: decision: str reason_codes: list[str] grant: BudgetGrant | None model_profile_override: str | None None review_target: str | None None从default_basic与fake_tiered两个策略的实现看decision实际取值包括decision含义触发场景default_basicgrant批准请求返回BudgetGrant低风险探针、强证据请求downscope批准但降低额度强证据但超出策略上限fake_tiered 演示require_review需要人工/规划 Agent 审查弱证据且超预算review_targetchairdeny拒绝非法单位、impossible标志reason_codes是可机读的拒绝/降档原因列表便于下游报告与审计review_target指明把审查路由给谁默认是chair即 Chair 规划 Agent。3.2 默认策略default_basic的判定规则PRAXIST 仓库自带的默认策略位于 praxist/plugins/budget_policies/default_basic/policy.py其decide()逻辑可以完整还原为四步流水线第一步单位与数值合法性校验。调用 praxist/core/budget.py 的_invalid_budget_units单位必须属于ALLOWED_BUDGET_UNITS数值必须能转成float、必须有限math.isfinite且非负。任何非法单位直接denyif invalid_units: return BudgetDecision( decisiondeny, reason_codes[invalid_budget_value, *invalid_units], grantNone, review_targetNone, )第二步不可能请求直接拒绝。当expected_value携带impossible: True标志时拒绝该请求reason_code 为impossible_request。这是「结果保留」姿态下的止损开关一个在预期价值层面就标注为不可能的请求不应浪费任何预算。第三步强证据请求内部放行。当expected_value[confidence] strong且evidence_refs非空时按请求原额批准并附带两条执行条件grantBudgetGrant( grant_idfgrant_{request.request_id}, approveddict(request.requested), conditions[record_actual_usage, abort_on_no_signal], expires_at_generationNone, )注意BudgetGrant的字段见 praxist/core/protocol.pygrant_id唯一标识、approved是批准额度字典、conditions是执行条件、expires_at_generation是过期代数None表示不过期。第四步廉价探针自动放行其余路由审查。当tokens 5_000且wall_clock_seconds 120且gpu_hours 0时视为低风险探针自动grantcheap_probe_auto_grant无附带条件否则返回require_review并依据置信度选择 reason_codereturn BudgetDecision( decisionrequire_review, reason_codes[ weak_evidence_over_budget if confidence weak else budget_requires_review ], grantNone, review_targetchair, )这四步规则直接呼应了原文档的「自动放行低风险 / 审查异常大请求 / 拒绝损害运行请求」三类行为并用确定性代码固化了边界5000 tokens、120 秒、0 GPU 小时。3.3 插件的注册与加载capability 与 entrypoint策略不是硬编码在核心里的而是通过插件机制注册。default_basic的清单 praxist/plugins/budget_policies/default_basic/plugin.yaml 声明schema_version: 1 name: default_basic kind: budget_policy version: 0.1.0 protocol_version: 1 stability: v1_stable capabilities: - budget.decide entrypoint: policy:create_policy code: - policy.pykind: budget_policy决定了插件引用形式为budget_policy:namecapabilities: [budget.decide]声明该插件具备的预算决策能力entrypoint: policy:create_policy指向 policy.py 的工厂函数create_policy()返回DefaultBasicBudgetPolicy实例。加载与分发由 praxist/core/budget.py 的policy_for_ref完成解析PluginRef→ 用PluginLoader解析清单 → 通过require_execution_plugin校验kindbudget_policy与capabilitybudget.decide→ 校验插件对象具有decide方法后返回。整个加载过程要求enforce_bundled_executionTrue即执行类插件必须来自可信的 bundled 来源。四、默认姿态结果保留Result Preservation原文档特别强调The default posture is result preservation. A promising experiment should be allowed to finish when it is inside a reasonable envelope and can produce useful artifacts, even if exact metering is imperfect.预算治理的目标不是「省到极致」而是「让有希望的实验在合理包络内跑完并产出有用工件」。这一点在实现层有明确的工程体现——praxist/core/execution_guards.py 中BudgetedActionGuard的类注释写得很直白Record per-action usage without making observability a result killer.即记录每个动作的用量但绝不让可观测性成为结果的杀手。具体做法包括高成本动作开始前如果require_budget_grantTrue而尚未取得批准 grant会抛出ResourceBudgetErrorpraxist/core/execution_guards.py阻止「无授权的高成本动作」启动但正常执行中守卫只负责记录不阻断实验本身用量核算缺失时走usage_unknown通道见第五节由重放阶段给出警告而非直接判死。BudgetedActionGuard提供两条构造路径from_env()从PRAXIST_RUN_DIR、PRAXIST_RUN_ID、PRAXIST_BUDGET_GRANT_ID、PRAXIST_BUDGET_REQUEST_ID等环境变量恢复上下文from_run_config()则从显式RunConfig构造供 CLI 边界已有RunConfig的调用方使用。两条路径产生等价的守卫保证「同配置同行为」。五、使用记录Usage Records精确、估计、部分与未知5.1 四种记录形态原文档规定使用记录可以精确exact、估计estimated、部分partial或未知unknown。在账本实现中praxist/core/ledgers.py 的BudgetLedger提供三类写入方法append_request(...)记录请求本身含request_record、requested_budgetappend_decision(...)记录决策结果decision、granted_budget、actual_usageNone并调用_validate_budget_amounts校验批准额度append_usage(...)记录实际用量actual_usage若超出发放 grant 的批准额度会通过_require_usage_within_grant生成budget_overrun: True、overrun_units、overrun_details标记append_usage_unknown(...)记录「用量未知」事件见 5.2 节。账本统一以 JSONL 追加写入运行目录run_dir每类记录共享record_id、request_id、grant_id、actor_ref、stage_id、action_type、reason等基字段保证后续重放可以按 grant 归并核算。5.2usage_unknown未知必须显式记录而非写成 0这是原文档中语义最严格的一条Unknown usage must be recorded explicitly asusage_unknowninstead of0.把「未知」写成0会造成两种危害一是预算报告把未测得的消耗误报为零二是重放校验会把「批准了但没有任何用量记录」视为账本缺口。因此 PRAXIST 用usage_unknown这一专门的记录种类来承载「这单位确实消耗了但我们测不到准确值」。append_usage_unknown的约束praxist/core/ledgers.py非常严格grant self.require_active_grant(grant_id) approved grant.get(granted_budget) or {} ... for unit in normalized_units: if unit not in approved: raise ValueError( fBudget usage_unknown unit not approved by grant {grant_id}: {unit} )即usage_unknown只能针对该 grant 已批准的单位声明未批准的单位直接抛ValueError。这堵死了「借未知之名绕过授权」的路径——未知的是用量数值不是授权范围。5.3 核算缺失时的工作流行为从 praxist/plugins/workflow_stages/research_loop/stage.py 可以看到research_loop 阶段在执行后会检查授予额度中是否有单位缺失用量测量若missing_usage_units非空则调用ledger.append_usage_unknown(...)写入usage_unknown记录同时在阶段结果 summary 中追加警告budget usage measurement unavailable for approved units: units并把usage_unknown_units写入 summary阶段状态仍为succeeded。这正是「Late accounting failure should warn and preserve findings when possible」的代码级落实核算迟到/缺失时警告并保留成果而不是丢弃实验产出。六、策略接入方式任务级默认与 CLI 覆盖预算策略的选型贯穿「默认合理、按需覆盖」的原则。在 praxist/plugins/workflow_stages/research_loop/startup.py 中def default_budget_policy_for_task(task_ref: str, budget_policy_ref: str | None None) - str: Return the default budget policy reference for a task descriptor. if budget_policy_ref: return budget_policy_ref if task_ref task:fake_panel: return budget_policy:fake_tiered return budget_policy:default_basic未显式指定时普通任务默认使用budget_policy:default_basic测试专用任务task:fake_panel默认使用测试夹具budget_policy:fake_tiered任务描述符task descriptor或调用方可以显式传入budget_policy_ref覆盖默认值。在 CLI 层面praxist/run.py 提供--budget-policy参数python -m praxist run --task-ref task:xxx --budget-policy budget_policy:default_basic --run-dir ./runbudget_policy_ref会随 runtime、model_provider 一起进入插件解析清单plugin_refs.extend([runtime_ref, model_provider_ref, budget_policy_ref])见 praxist/plugins/workflow_stages/research_loop/startup.py并在运行摘要中以budget_policy: budget_policy_ref记录保证每次运行的策略选择可追溯。七、账本查询与执行门槛BudgetLedger不仅写记录还提供两个关键查询供执行层决定「还能不能跑」active_grants()praxist/core/ledgers.py扫描所有kind decision且granted_budget非空的记录返回活跃 grant 字典get_exhausted_units(grant_id)praxist/core/ledgers.py把该 grant 已累计用量与批准额度逐单位比对返回已耗尽的单位列表信息型单位cost_usd、neurons被显式跳过「只上报、不卡执行」。require_active_grant(grant_id)则在找不到 grant 时抛ValueError保证任何usage_unknown或后续核算都必须挂接在真实存在的授权之上。八、测试与重放校验预算契约的防线8.1 预算测试应覆盖的场景原文档给出了预算策略测试的覆盖清单grant、deny、downscope、review routing、usage_unknown、replay visibility、以及「peer 在用量核算完成前就产出结果」的行为。仓库中对应测试位于 tests/conformance/test_core_plugin_contracts.py 的test_budget_policy_conformance_cases用budget_policy:fake_tiered把四类出口逐一打满输入预期决策断言要点tokens1000, wall_clock_seconds30, weak 置信度grant廉价探针自动放行grant非空tokens80000, wall_clock_seconds3600, gpu_hours4, strong evidencedownscopegrant.approved[gpu_hours] 2.0被上限截断tokens80000, weak、无证据require_review路由到 Chair 审查expected_value{impossible: True}deny不可能请求直接拒绝测试夹具策略见 tests/fixtures/plugins/budget_policies/fake_tiered/policy.py它额外演示了downscope降档的完整语义——强证据请求若超过策略上限tokens5_000_000、wall_clock_seconds172_800、gpu_hours2.0会按上限截断批准额度若请求标记requires_full_stage_budget而截断后额度不满足则升级为require_review。这补全了default_basic未覆盖的「降档」路径也是原文档「downscope a request」的权威实现参考。8.2 重放可见性账本在 replay 阶段的二次校验预算记录的重放可见性由 praxist/core/replay.py 保证。重放校验器逐条扫描账本kind usage_unknown的记录必须引用真实存在的 grantmissing grant_id/references unknown grant_id均报错unknown_units必须是列表且其中每个单位都必须在对应 grant 的approved中uses unapproved budget unit报错校验通过后该 grant 被标记为「已有用量未知记录」并追加警告budget usage_unknown for grant id: units对于一个成功执行过的运行若存在 grant 却完全没有usage或usage_unknown记录则警告budget ledger missing usage or usage_unknown record for executed successful runpraxist/core/replay.py。这套二次校验把「grant 批准了就必须有核算痕迹实测或显式未知」固化为可机器检查的契约确保usage_unknown不会被用来掩盖账本缺口。此外 praxist/plugins/workflow_stages/research_loop/backend/parity.py 的奇偶校验还会检查预算记录中是否出现eval_runner、gpu_slot、tool.wait_for_file等预期动作类型验证预算核算确实覆盖了关键资源动作。8.3 插件可执行闭包测试tests/conformance/test_plugin_executable_closure.py 对budget_policy:default_basic做可执行闭包检查加载清单后registry.require(budget_policy, default_basic)必须返回带decide方法的对象。同时它对 praxist/core/budget.py 有「禁标记」约束POLICY_CAPABILITIES不允许出现在该模块防止注册表能力泄漏到核心模块从结构上保证策略能力由插件清单声明、由注册表统一分发。九、把预算策略接入你自己的运行综合前文在 PRAXIST 中启用与定制预算治理的完整路径是了解当前策略默认任务走budget_policy:default_basicpraxist/plugins/budget_policies/default_basic/policy.py四步判定规则见第三节用 CLI 覆盖python -m praxist run ... --budget-policy budget_policy:namepraxist/run.py或通过任务描述符的budget_policy_ref指定编写自定义策略实现decide(request: BudgetRequest) - BudgetDecision方法协议定义见 praxist/core/budget.py并在插件清单中声明kind: budget_policy、capabilities: [budget.decide]、entrypoint: module:create_policy遵守单位与数值契约只使用tokens、wall_clock_seconds、gpu_hours以及信息型的cost_usd、neurons数值须有限且非负否则会被_invalid_budget_units拒绝正确报告未知用量测不到精确用量时调用BudgetLedger.append_usage_unknown显式声明usage_unknown且只能针对 grant 已批准的单位——不要写 0也不要越权声明未批准单位用测试锁住契约参照 tests/conformance/test_core_plugin_contracts.py覆盖 grant / deny / downscope / require_review / usage_unknown / replay visibility 全场景。小结PRAXIST 的预算治理是一套「请求—决策—记录—强制—重放校验」的动态闭环BudgetRequest承载预估成本与预期价值BudgetPolicy插件按确定性规则给出 grant / downscope / require_review / deny 决策BudgetLedger以 JSONL 账本忠实记录请求、决策、用量与usage_unknownBudgetedActionGuard在不杀死成果的前提下按 grant 核算每个高成本动作最后由replay与奇偶校验把「批准必有核算痕迹」固化为可机器检查的契约。理解了这套机制你就能在 PRAXIST 上按任务、按阶段灵活配置预算策略既守住算子限制又保住有希望的实验结果。赞分享人工智能AI Agent多智能体Agent 工作流深度研究AI 评测【免费下载链接】PRAXISTAutonomous research system for measurable, computer-executable research.项目地址https://gitcode.com/gh_mirrors/pr/PRAXIST点击查看免费下载相关推荐WeChatMsg 快速上手指南如何把微信聊天记录导出为 HTML、Word 和 CSVWeChatMsg 快速上手指南如何把微信聊天记录导出为 HTML、Word 和 CSV WeChatMsg 是一款开源工具用于提取微信聊天记录并导出成 HPhotoGIMP 免费补丁完整指南把 GIMP 3.0 改造成 Photoshop 风格的操作界面PhotoGIMP 免费补丁完整指南把 GIMP 3.0 改造成 Photoshop 风格的操作界面 PhotoGIMP 是一个免费开源的界面配置补丁专为从从 0 到 1 完整指南Higress Nacos 服务发现与动态路由怎么配从 0 到 1 完整指南Higress Nacos 服务发现与动态路由怎么配 先说结论把 Higress Nacos 服务发现 接起来之后路由的上游不再是API网关后端云原生LLM 网关人工智能MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考