D4Day 4 View
返回总览 周计划原文 合并文档原文
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7
Runtime

Day 4 Orchestrator 运行时

Day 4 把整个系统第一次串成“能跑的链”。用户消息和定时任务都先走 Orchestrator，由它创建 run、调用语义解析、做权限判断、选择 Agent、记录 ToolCall 和 Trace，然后再给下游执行。

上游依赖
Day 3 的语义解析结果，Day 1 的 Run / ToolCall，Day 2 的 active 资产。
下游交接
Day 5 User Agent 和 Day 6 Hermes 都通过它被调度。
当天关键
权限拦截和 Trace 必须在 Orchestrator 层，而不是散落在各 Agent。
Three-Layer Mapping

三层文档映射

路线图

周计划要求建立统一调度层，让用户请求和系统任务都先进入 Orchestrator，再根据语义、权限、能力注册路由到 User Agent、Hermes、MCP 或规则引擎。

day_4_orchestrator_runtime.md

执行细则

执行层拆成输入输出、Orchestrator 服务、路由规则、权限判断、能力查询、工具调用封装、API、最小 Trace 查看和测试。

agent week plan/day_4

架构依据

主要受运行时流程、能力注册、权限确认和可观测性约束。Day 4 的输出要能直接给前端展示，并支持 Day 5/6 的占位实现接入。

04 07 08 09
Build Order

推荐开发顺序

Step 1先定 OrchestratorRequest 和 OrchestratorResponse。
Step 2写 run(request) 主流程：创建 Run、解析语义、判权限、选 Agent、更新状态。
Step 3把用户入口 / 任务入口的路由规则固化下来。
Step 4封装工具调用记录和降级策略。
Step 5暴露 API 和最小 Trace 页面或接口。
Must Deliver

今天必须产出的东西

统一入口

  • source=user_message 与 source=schedule 都能进同一入口。
  • 请求返回 run_id、selected_agent、route_reason、permission_level。
  • 返回结果要能被前端直接展示。

权限与路由

  • 查询类走 User Agent，定时风险类走 Hermes。
  • approval_required 只返回确认，不直接执行。
  • forbidden 直接阻断，不调下游 Agent。

能力与工具调用

  • 只查询 active 技能 / MCP / 任务。
  • 禁用能力不允许被调用。
  • 每次工具调用都能落 AgentToolCall。

Trace 与降级

  • Trace 能串起语义解析、路由、工具调用和最终结果。
  • 外部 MCP 失败要返回降级说明，不让前端拿到不可读错误。
  • 异常都要写进 AgentRun.error_message。
Acceptance Snapshot

验收快照

路由结果
同一句风险检查，在用户入口和任务入口会有不同路由结果。
权限边界
“直接上线规则”和“直接付款”都不会被自动执行。
日志完整度
每次运行至少有一条 AgentRun，工具调用有 0 到多条 AgentToolCall。
可观察性
前端或 curl 可以完整看到一次运行链路，不需要直接查数据库猜过程。
Common Misses

这一天最容易漏掉的点

Day 4 的价值是把系统从“有很多零件”变成“有一条统一运行链”。