这篇适合谁看
如果团队已经能让一个 Agent 在本地跑通，但一进入真实业务就卡在文件访问、长期上下文、人工审批、并行子任务、日志追踪和部署隔离上，这篇 Microsoft Agent Framework 的 Build 2026 发布就很值得拆。它的重点不是再讲一个聊天机器人，而是把 Agent Harness、Hosted Agents、CodeAct、Copilot SDK 和 Handoff 编排放在同一个工程框架里，让本地原型有机会变成可部署、可观测、可恢复的系统。
核心架构怎么拆
可以把它拆成三层。第一层是 Harness，负责把模型推理接到真实执行环境，包括文件系统、shell、待办事项、模式切换、技能发现、上下文压缩和人工审批。第二层是 Hosted Agents，把本地 Agent 打包成容器，交给 Foundry Agent Service 托管，获得身份、会话状态、弹性伸缩、隔离和 Application Insights 可观测性。第三层是编排与加速，CodeAct 用一次沙箱代码执行减少多轮小工具调用，Handoff 用有向图声明多个专业 Agent 之间的转交关系。
落地时先做一条最小链路
- 先选一个有明确输入、输出和审批点的内部任务，例如报告生成、故障初筛、代码仓库巡检或工单分派。
- 把 Agent 能访问的文件、目录、外部工具和网络边界列成清单，不要让模型自由猜。
- 用 Harness 管住上下文和任务状态，长任务必须有 todo、日志和中途恢复机制。
- 把危险动作统一接到审批工具，审批记录要能回放，不能只靠口头约定。
- 本地通过后，再把同一套 Agent 封装成 Hosted Agent，验证会话隔离、状态持久化和 scale-to-zero 之后的恢复。
CodeAct 适合放在哪里
CodeAct 不应该替代所有工具调用。它适合那种工具很多、步骤细碎、每一步都要回模型确认一次的场景，例如批量读取数据、汇总多个接口、对几十个文件做同类检查。Microsoft 的发布里给出的方向很清楚，它让模型写一小段程序来调用工具，并放进隔离沙箱执行，目标是降低延迟和 token 消耗。团队落地时要给 CodeAct 单独的工具白名单、运行时间上限、输出大小限制和审计日志。
最容易踩的坑
第一，不要只看 SDK 代码示例就上线，生产 Agent 的难点往往在权限、回滚、监控、成本和人机交接。第二，不要把所有工具都暴露给同一个 Agent，工具越多，模型越容易在相似工具之间选错。第三，Handoff 图谱不要画得太复杂，先从 triage、specialist、reviewer 三类角色开始。第四，Hosted Agent 的会话状态要有清理策略，否则长跑任务和文件记忆会变成新的运维负担。
建议产出
读完后可以直接产出一份企业 Agent Harness 设计表，字段包括任务名称、可访问文件、可调用工具、审批动作、状态存储、日志位置、失败恢复、部署形态和负责人。只要这张表还说不清，说明这个 Agent 还停留在 demo 阶段，不适合接真实业务。