一个运行时角色至少包含这些东西：
- 它什么时候被选中。
- 它能看什么上下文。
- 它能看见哪些工具。
- 它能不能执行动作。
- 它执行动作前是否需要审批。
- 它每一步如何停止、重试、降级。
- 它最后必须交付什么结构。
- 它出错后如何追踪和修复。
- 它优化以后，如何证明没有影响其他 Agent。
这些问题都不是静态 Prompt 能独立解决的。
没有 Code-driven Assembly，多个 Agent 很容易变成"多个不同人设的聊天窗口"。有了 Code-driven Assembly，Agent 才能成为一个可治理、可复现、可测试、可持续优化的运行时组件。
一、先把 Agent Runtime 拆开看
要讲清楚 Code-driven Assembly，先要把单个 Agent Runtime 的层次讲清楚。很多争论来自一个误解：把 Agent Runtime 等同于 LLM 调用，或者等同于 Prompt。
一个实用的 Agent Runtime 至少有 9 层：
text
User Turn
-> Router
-> AgentDefinition
-> Assembly
-> PromptCompiler
-> Model Call
-> Tool Loop
-> Final Projector
-> Trace / Eval每层职责不同。
| 层级 | 负责什么 | 常见错误 |
|---|---|---|
| User Turn | 接收用户输入、附件、选择资源、会话状态 | 只把用户文本当输入 |
| Router | 决定哪个 Agent 处理 | 用关键词硬分流 |
| AgentDefinition | 描述 Agent 的稳定身份和默认能力 | 只有一个 prompt 文件 |
| Assembly | 动态决定本轮上下文、工具、策略、循环 | 分散在各处临时拼 |
| PromptCompiler | 把结构化 sections 编译成模型输入 | 各业务代码自己拼字符串 |
| Model Call | 调模型 | 把模型当成权限和流程引擎 |
| Tool Loop | 执行工具、观察结果、重试或停止 | 模型可见工具和实际可执行工具不一致 |
| Final Projector | 把模型输出投影成产品结果 | 直接把模型自由文本返回给用户 |
| Trace / Eval | 记录、复现、诊断、回归 | 只存最终答案，不存装配过程 |
这里最容易被低估的是 Assembly 层。