CONTROLLED AGENT · VERIFIED CANDIDATE
从控制流原型，走向真实工具运行
服务端运行时已经能够规划并读取真实知识与项目证据；下方五类固定轨迹继续承担权限、预算、重试和审批的安全回归基线。
SERVER RUNTIME · CANDIDATE 02
让每一步都可验证、可恢复
任务在服务端逐轮规划；每个工具结果经过 Schema、权限和预算守卫，并在可用仓储中写入版本化检查点。
- 真实只读工具
- 2
- 契约评测
- 20
- 夹具通过率
- 100%
运行后，这里会显示服务端模式、真实工具结果与逐步轨迹。
OBSERVABILITY · TRACE → OTEL
同一条轨迹，换成业界标准语言
运行结束后可导出一份对齐 OpenTelemetry GenAI 语义约定的 span JSON（结构对齐的 resourceSpans/scopeSpans/spans， 不是完整 OTLP wire format，也不依赖 @opentelemetry/sdk）。映射关系：
一次运行根 span invoke_agent liujixue-controlled-agent；run.status → span status（completed→OK，failed/budget_exceeded→ERROR，waiting_approval/rejected→UNSET）。
每个规划轮次真实模型模式为 chat <model>（CLIENT），确定性 planner 为 plan（INTERNAL），均带 gen_ai.operation.name。
每次工具调用execute_tool <tool> 子 span：gen_ai.tool.name、gen_ai.tool.call.id、gen_ai.tool.call.arguments/result；守卫、审批等待与审批结果记录为 span event。
token 用量根 span 的 gen_ai.usage.input_tokens/output_tokens（含 cache_read/cache_creation）；仅真实模型模式输出，夹具模式省略而非伪造。
为什么生产 agent 需要标准可观测性：属性命名统一后，同一份 span 可以送进 Jaeger、Grafana Tempo、Datadog 等任何 OTel 后端，跨框架排障与对比，不被单一厂商格式锁定；接生产后端时用官方 SDK 按同一约定重新仪表化即可。
在 MCP 协议层观察同一批只读工具（initialize → tools/list → tools/call）
所有工具调用先经过权限、审批和步数预算；当前执行器只运行仓库内确定性夹具，不连接真实外部工具。
ACTIVE RUN
正常完成
读取本周业务指标，生成周报并保存为草稿。
- 工具步数
- 3 / 5
- 受控重试
- 0
- 副作用提交
- 1
EVENT TRACE
执行轨迹回放
- 1计划已创建
拆分为 3 个受控动作，最大工具步数 5。
- 2进入执行
状态从 planned 转为 running。
- 3读取业务指标
读取本周业务指标
- 4工具执行成功
只读结果已写入状态。
- 5生成周报草稿
将指标组织成周报
- 6工具执行成功
只读结果已写入状态。
- 7保存周报草稿
保存周报草稿
- 8工具执行成功
副作用已提交一次并写入事件日志。
- 9任务完成
所有计划动作完成，控制器停止循环。