Microsoft Agent Framework 的变化不只是一次版本升级。随着 Agent Harness 与 Foundry Hosted Agents 进入正式可用阶段，微软正在把关注点从“如何编写智能体”推进到“如何稳定、可控地运行智能体”。在 Build 2026 发布并逐步稳定的能力中，还包括 GitHub Copilot、Claude Agent SDK 连接器以及多种编排模式。
这意味着团队评估智能体框架时，不能只看模型调用是否方便、工具接口是否简洁，还要回答运行隔离、权限审批、执行追踪、失败恢复和版本治理等工程问题。
Agent Harness 改变了运行边界
传统 Agent SDK 通常解决三个核心问题：构造提示词、调用模型、注册工具。应用进程本身仍然承担调度、状态管理、凭据注入和错误处理。一旦智能体能够修改代码、访问工单或执行外部命令，这种做法会迅速放大风险。
Agent Harness 的价值在于为智能体执行提供受支持的运行边界。结合来源摘要，可以把它理解为平台层的一次前移：开发者仍然编写智能体逻辑，但运行时开始承担更多标准化职责。
这种变化会影响系统设计：
- 智能体定义与执行环境需要解耦，避免把业务逻辑、密钥和模型会话塞进同一个常驻进程。
- 工具调用应被视为具有权限和副作用的操作，而不是普通函数调用。
- GitHub Copilot 与 Claude Agent SDK 等连接器应位于明确的适配层后面，业务工作流不应依赖某个连接器的私有消息格式。
- 编排流程需要记录任务、步骤、审批和输出，以便故障排查与审计。
GA 并不代表所有治理问题都会自动解决。它表示相关运行能力已经进入可获得正式支持的阶段；具体提供哪些隔离、身份、网络和审计控制，仍需按照实际产品文档及部署环境逐项验证。
从单个 Agent 转向可治理的工作流
智能体原型往往只有一条直线：接收请求、调用模型、执行工具、返回结果。生产工作流更像一个带状态的任务系统。例如，代码维护智能体可能需要经过以下步骤：
- 读取仓库和问题描述。
- 生成修改计划，但暂不写入代码。
- 在权限允许的工作区内实施修改。
- 运行测试并收集结果。
- 对发布、合并或生产变更请求人工审批。
这里的关键不是使用多少个 Agent，而是每一步是否有明确的输入、输出、权限和终止条件。所谓编排模式进入稳定版本，真正值得关注的是团队能否把上述流程表达为可观察、可恢复的执行图，而不是堆叠更多自主循环。
连接器同样应该被当成基础设施依赖管理。可以为每种连接器定义统一契约，例如 prepare、execute、cancel 和 collect_result，再由适配器处理不同 SDK 的会话与事件格式。这样更换模型提供方或增加新的执行后端时，不必重写整个业务流程。
可以这样实践：在部署前验证 Agent 策略
下面是一个独立于具体微软 API 的最小治理示例。它不是 Agent Framework 或 Foundry 的官方配置格式，而是团队可以放进仓库和 CI 的部署前策略。运行前需要安装 Python 3.10 以上版本和 PyYAML。
创建 agent-policy.yaml：
version: 1
agent:
name: repo-maintainer
environment: staging
connectors:
allowed:
- github-copilot
- claude-agent-sdk
tools:
allowed:
- repository.read
- repository.write
- tests.run
denied:
- production.deploy
- secrets.export
limits:
max_steps: 20
timeout_seconds: 900
approval:
required_for:
- pull_request.merge
- production.deploy
再创建 validate_policy.py：
from pathlib import Path
import sys
import yaml
REQUIRED_APPROVALS = {"pull_request.merge", "production.deploy"}
FORBIDDEN_TOOLS = {"secrets.export"}
def main() -> int:
path = Path(sys.argv[1] if len(sys.argv) > 1 else "agent-policy.yaml")
policy = yaml.safe_load(path.read_text(encoding="utf-8"))
errors = []
agent = policy.get("agent", {})
allowed = set(policy.get("tools", {}).get("allowed", []))
approvals = set(policy.get("approval", {}).get("required_for", []))
limits = policy.get("limits", {})
if not agent.get("name"):
errors.append("agent.name is required")
if allowed & FORBIDDEN_TOOLS:
errors.append("forbidden tools cannot appear in tools.allowed")
if not REQUIRED_APPROVALS.issubset(approvals):
errors.append("merge and production deployment must require approval")
if not 1 <= limits.get("max_steps", 0) <= 50:
errors.append("limits.max_steps must be between 1 and 50")
if not 1 <= limits.get("timeout_seconds", 0) <= 3600:
errors.append("limits.timeout_seconds must be between 1 and 3600")
if errors:
for error in errors:
print(f"ERROR: {error}")
return 1
print(f"Policy accepted for agent: {agent['name']}")
return 0
if __name__ == "__main__":
raise SystemExit(main())
执行验证：
python -m venv .venv
. .venv/bin/activate
python -m pip install PyYAML
python validate_policy.py agent-policy.yaml
在 Windows PowerShell 中，将激活命令替换为：
.venv\Scripts\Activate.ps1
这个例子没有假设 Agent Harness 的具体 API，而是展示一条可落地的治理路径：将连接器白名单、工具权限、执行上限和人工审批写成版本化配置，再由 CI 在部署 Hosted Agent 之前进行验证。接入真实平台时，可以把验证通过的配置转换为平台支持的部署参数。
采用 GA 平台前应检查什么
从 SDK 转向托管运行时，团队会减少部分运行维护工作，但也会引入平台依赖。正式采用前，建议完成以下检查：
- 确认 Harness、Hosted Agents、连接器和编排组件各自的支持范围，不要把其中一个组件的 GA 状态推断为整套依赖全部 GA。
- 验证身份传播方式，明确 Agent、最终用户与工具服务分别使用什么身份。
- 检查网络出口、密钥存储、数据驻留、日志保留和敏感字段脱敏能力。
- 为工具调用设置默认拒绝策略，对写入、合并、部署和删除操作增加审批。
- 测试超时、重复事件、部分执行成功、连接器不可用和模型拒答等异常路径。
- 保存 Agent 定义、提示词、工具版本和策略版本，使一次执行能够被解释和复现。
Agent Harness 和 Foundry Hosted Agents 的 GA，标志着 Microsoft Agent Framework 开始具备更明确的生产运行定位。真正的收益不会来自把现有聊天循环原样搬进托管环境，而是来自重新划分责任：SDK负责表达智能体行为，连接器负责适配执行后端，编排层负责推进任务，而运行平台负责承载受约束、可观察的执行。团队越早把权限、审批和故障边界写进系统设计，越容易把智能体从演示功能变成可运营的软件能力。