为什么要把 Build Session 当学习路线
Microsoft Agent Framework 在 Build 2026 的 Session 列表其实是一张能力地图。它把 Claw 与 Agent Harness、生产级部署、开源 Agent 治理、可观测性评测、Foundry 集成、多 Agent 实战放在一起。对团队来说，这比单看某个 SDK 文档更有价值，因为它透露了 Microsoft 认为生产 Agent 必须补齐的能力栈。
第一周先补 Agent Harness
学习路线的第一站应该是 Agent Harness。不要急着写复杂工作流，先搞清楚一个 Agent 怎样稳定使用文件、工具、浏览器、shell、MCP、技能和长期上下文。可以拿一个很小的仓库审查任务练手，让 Agent 读取文件、列 todo、生成修改建议、等待人工确认，再输出最终报告。这个阶段的目标不是酷，而是确认每一步都有记录、可暂停、可恢复。
第二周补生产部署和运行边界
第二站是 From prototype to production。Agent 从原型到生产，核心差异是身份、状态、隔离、日志、成本和版本。建议团队给每个 Agent 明确四个边界，能读什么、能写什么、能调用什么、什么时候必须停下来找人。再补一张部署表，记录运行环境、容器镜像、密钥来源、网络出口、日志面板和回滚方式。
第三周补治理、评测和可观测
如果 Agent 不能解释自己为什么这么做，后续很难进入企业流程。Build Session 里关于 governance、observability 和 evals 的内容，应该单独拆出来做一周。最小实践是为每个 Agent 记录输入、计划、工具调用、审批、输出和失败原因，再用规则评测和人工抽检共同判断结果质量。不要只看最终回答是否像样，真实业务更关心过程是否可审计。
第四周再做多 Agent 编排
多 Agent 很容易做成热闹但不可控的表演。更稳的做法是先定义角色，再定义转交边。比如一个 triage agent 负责识别请求类型，一个 engineer agent 负责修改建议，一个 reviewer agent 负责检查风险。每条 handoff 都要有理由、输入摘要和失败兜底。只有单 Agent 的状态、日志和审批都稳定之后，多 Agent 才有意义。
团队作业怎么设计
- 选择一个真实但低风险的内部任务，例如文档补全、依赖升级建议、客服知识库整理。
- 按四周路线分别产出 harness demo、部署说明、观测面板和 handoff 图。
- 每周只接受一项新增能力，避免同时引入太多变量。
- 最后用同一批输入跑三次，比较结果稳定性、成本、人工介入次数和失败类型。
验收标准
这条学习路线跑完后，团队至少应该能回答，Agent 失败时谁知道、危险动作谁审批、状态存在哪里、日志怎么看、版本怎么回滚、多人协作时谁负责最终输出。回答不上来，就不要急着把 Agent 接到生产系统。