实用提示：适用于人工智能智能体的最小可行实验平台
《实用笔记》操作指南：面向人工智能智能体的最小可行实验平台——为采用该模式的团队提供的合约、校验机制以及可直接插入的代码模块。
以下内容为围绕“AI智能体的最小可行实验平台”所设计的实用路径。重点在于契约、校验机制以及可直接插入的代码占位符，而非动机性阐述。 在完成概览阶段时，首先明确契约内容：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持清晰。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。
agent runtime
memory and retrieval
system prompt
model
tools
guardrails
application logic
should version B replace version A?
明确B的真正含义
将“定义B的实际阶段”视为可测量的界面时效果最佳。在扩大范围之前，先记录一份理想的测试用例、一个失败案例以及回滚说明。 将此阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，绝不允许默许部分完成的情况。 保持图结构的状态简洁且类型明确。嵌套的数据块会掩盖哪个节点修改了哪个字段，还会在中断后导致无法继续处理。
A = agent-v17
B = agent-v18
pipeline:
name: support-agent
version: 18
components:
runtime:
artifact: agent-runtime@sha256:...
memory:
artifact: memory-service@sha256:...
configuration:
strategy: hybrid
top_k: 8
model:
route: support
model: provider/model-x
prompt:
artifact: sha256:...
tools:
- artifact: customer-lookup@sha256:...
- artifact: refund-tool@sha256:...
model X vs model Y
memory top_k=5 vs top_k=8
任务分配并非（另一项）生产环境依赖
将该任务视为可度量的对象来处理，效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，就能避免在从演示环境过渡到共享环境时出现意外费用。要保持图结构的层次简单且类型明确，嵌套的数据块会掩盖是哪个节点修改了哪个字段，还会在出现中断后导致程序无法继续运行。
request
user
session
workflow_instance
workflow_instance = migration-8291
variant = B
pipeline = agent-v18
任务并非公开暴露的内容
“任务并非暴露阶段的最优处理方式，将其视为可度量的界面反而更有效。在扩大范围之前，需记录一份理想状态下的日志、一个故障案例以及回滚说明。
应将配置与应用程序代码分开。环境文件、密钥存储和功能标志应集中存放于一处，以便操作人员无需查看整个系统结构即可进行审计。
保持系统状态的简洁性与类型化。嵌套的数据结构会掩盖具体是哪个节点修改了哪个字段，还会导致中断后无法继续执行。
“任务并非暴露阶段的最优处理方式，将其视为可度量的界面反而更有效。在扩大范围之前，需记录一份理想状态下的日志、一个故障案例以及回滚说明。
相比庞大的脚本，应优先使用小型且可测试的单元。当某个步骤出现故障时，故障点应指向单一责任模块，而非复杂的流程链。
ASSIGNMENT
user-18271 → B
EXPOSURE
memory-v2 retrieval started
assigned 10,428
exposed 8,912
exposure rate 85.46%
assigned_variant = B
realized_model = X
fallback_reason = provider_unavailable
追踪信息能解释所发生的一切
在修改代码之前，对于“追踪”阶段需说明发生了什么，明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 应将此阶段视为输入与已验证输出之间的契约。为相关成果命名，定义成功检查标准，并拒绝默许的半完成状态。 对于涉及资金支出或更改生产数据的操作，必须经过人工审批。编译时的连接并不等同于业务上的完整性。
experiment.id
experiment.version
experiment.variant
experiment.assignment_id
pipeline.id
pipeline.version
execution.purpose
B has a lower task completion rate
show failed B traces
assignment
exposure
outcome
feedback
evaluation
离线评估使用相同的流程
在离线评估阶段，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解这些成本可以避免在从演示环境切换到共享环境时出现意外费用。对于那些会消耗资金或修改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。
prompt
expected answer
scenario:
id: duplicate-charge-001
input:
message: >
I was charged twice for order 9811.
environment:
fixture: duplicate-charge-customer
expected:
refund_count: 1
ticket_status: resolved
limits:
max_turns: 15
max_tool_calls: 20
max_cost: 0.50
REPLAY_DIVERGED
影子执行架起了离线环境与生产环境之间的桥梁
对于 Shadow 执行桥接阶段，应在修改代码之前明确输入参数、该步骤的负责人以及退出条件。操作员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个操作员可审计的位置，无需阅读整个流程图。 对于涉及资金支出或修改生产数据的节点，需设置人工审批环节。编译时的连接方式并不等同于业务功能的完整性。 对于 Shadow 执行桥接阶段，应在修改代码之前明确输入参数、该步骤的负责人以及退出条件。操作员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 相较于庞大的脚本，应优先使用小型且可测试的单元。当某个步骤失败时，故障原因应指向单一责任模块而非多个部分。
带角度的管道。latency
cost
tool usage
model fallbacks
guardrail failures
judge scores
trajectory differences
并非所有情况都需要LLM来判断
在处理“并非所有情况都需要某个阶段”这一议题时，首先写下相关契约：所需的输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 将这一阶段视为输入与经过验证的输出之间的契约。为相关产物命名，明确成功检测标准，并拒绝默许部分完成的情况。 缓存稳定的系统指令和工具架构。重复发送相同的开头信息是造成资源浪费的常见原因。
refund_count == 1
ticket_status == resolved
helpfulness
clarity
tone
quality of explanation
evaluator
evaluator version
judge model
judge prompt
rubric
哦！关于统计数据
在处理“关于统计信息”这一阶段时，首先写下相关约定：所需输入、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。 在耗时较高的步骤之后设置检查点。当操作员重新尝试后续节点时，恢复流程不应再次收取相同的LLM调用费用。
A/B allocation
binary metrics
continuous metrics
95% confidence intervals
sample ratio mismatch detection
fixed-horizon analysis
Experiment
support-agent-v18
Randomization
user
Primary metric
ticket resolution
A 81.4%
B 85.1%
Difference
+3.7 percentage points
95% CI
[...]
Experiment health
SRM PASS
4 model calls
47 model calls
max cost / execution
max tokens / execution
max agent turns
max tool calls
max variant spend / hour
Variant B
SRM PASS
Error rate PASS
Cost / request +312%
Circuit breaker TRIPPED
New exposure PAUSED
应首先构建什么
在确定首先需要构建什么的内容时，首先要写明相关规范：所需的输入参数、成功标志，以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在耗时较高的步骤之后设置检查点。当操作人员重新尝试后续节点时，恢复流程不应再次调用相同的大型语言模型接口。 在确定首先需要构建什么的内容时，首先要写明相关规范：所需的输入参数、成功标志，以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 相比庞大的脚本，更应优先使用小型且可测试的单元。当某个步骤失败时，故障原因应能明确指向某个具体的功能模块，而非整个复杂的流程。
assignment
exposure
outcome
feedback
evaluation
what was randomized
what treatment was assigned
what treatment actually ran
what pipeline version produced the execution
what outcome was measured
how that outcome was evaluated
What exactly did we run?
What happened when we ran it?
Did assigning users to B improve the outcome we care about?
操作检查清单
在制定操作检查清单时，需明确输入参数、各步骤的负责人以及完成标准，然后再进行代码修改。操作人员应能够从已知的检查点重新执行相应步骤，而无需猜测隐藏状态。
需同时记录正常流程与故障恢复流程。重试机制、人工审核环节以及错误处理方式都是产品不可或缺的部分，而非后续需要补充的内容。
对于涉及资金支出或修改生产数据的操作，必须经过人工审批。仅靠编译时的配置并不足以确保业务的完整性。
编写简短的操作手册：包括如何轮换密钥、如何清空队列以及如何回滚最近的导入操作。
优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤出现故障时，故障原因应能明确指向具体的责任环节，而非复杂的流程链。
对于那些会消耗资金或更改生产数据的操作，必须经过人工审批。编译时的配置并不等同于业务功能的完整性。
在推广该技术栈之前，应先冻结版本，为关键流程记录完整的操作日志，并明确回滚步骤。共享环境需要设置速率限制、租户验证机制，以及明确的密钥轮换负责人。与其追求花哨的一次性演示，不如注重扎实的可靠性。
关于35a4ad1bbf8c的批注：请将服务提供商密钥存放在仓库之外，为每个会话设置令牌使用上限，并将操作日志与评估用配置文件放在一起，以便后续模型更换时仍能保持数据可比性。
在处理强化措施的第0阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合要求。
在功能结果旁记录执行时间以及代币或查询成本。提前了解这些成本，可避免在系统从演示环境过渡到共享环境时出现意外费用。
强化措施细节0/952：为该阶段测量实际执行时间、错误类型以及代币消耗情况，然后依据固定的评估标准而非主观判断来决定是否保留相关修改。
将强化措施的第1阶段视为可测量的对象来处理效果最佳。在扩大范围之前，先记录一个理想运行案例、一个失败案例以及回滚说明。
应同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理方式都是产品本身的组成部分，而非后续需要补充的内容。
强化措施细节1/952：记录该任务的执行时间、错误类型以及代币消耗情况，然后依据固定的评估标准而非个人经验来决定是否保留该变更。
在强化措施的第二阶段，应在修改代码之前明确输入参数、该步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应将此阶段视为输入参数与验证后输出结果之间的契约，为相关成果命名、定义成功判定条件，并拒绝默许部分完成的情况。
强化措施细节2/952：记录该任务的执行时间、错误类型以及代币消耗情况，然后依据固定的评估标准而非个人经验来决定是否保留该变更。
在处理强化措施的第3阶段时，首先写下相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合规范。 应将配置信息与应用程序代码分开。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。
强化措施细节3/952：针对该措施需统计执行耗时、错误类型以及令牌使用情况，然后依据固定的评估标准而非个人经验来决定是否保留该变更。
将强化措施的第4阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份标准操作流程、一个失败案例以及回滚说明。 相比复杂的脚本，更应采用小型且可测试的单元。当某个步骤出现故障时，故障原因应能明确指向某个具体职责，而非整个混乱的流程链。
强化措施细节 4/952：记录该任务的执行时间、错误类型以及代币消耗情况，然后依据固定的评估标准而非个人经验来决定是否保留该变更。
在强化措施的第5阶段，应在修改代码之前明确输入参数、该步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。应在功能结果旁记录执行时间以及代币或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
强化措施细节 5/952：记录该任务的执行时间、错误类型以及代币消耗情况，然后依据固定的评估标准而非个人经验来决定是否保留该变更。