Microsoft Agent Framework 的变化不只是多了几个连接器。随着 Agent Harness 与 Foundry Hosted Agents 进入正式可用阶段，重点已经从“如何写出一个 Agent”转向“如何稳定、受控地运行 Agent”。GitHub Copilot 和 Claude Agent SDK 连接器、编排模式及受支持运行时共同构成了这次平台化升级。
Agent Harness 补上了生产运行层
SDK 通常解决模型调用、工具定义和消息传递，却不会自动解决生产环境中的身份、权限、审计、超时、故障恢复和资源隔离。团队可以很快做出 Agent 原型，但要把它接入企业系统，仍需自行搭建大量运行基础设施。
Agent Harness 的意义在于把这部分能力提升为明确的运行层。开发者仍然负责 Agent 的目标、提示词、工具和业务规则；平台则负责约束 Agent 如何执行、能够访问什么，以及运行过程如何被观察和治理。
这也改变了架构边界：
- Agent SDK 描述 Agent 的能力，包括模型、工具和对话逻辑。
- Harness 管理一次执行，包括上下文、策略、生命周期和遥测。
- Hosted Agents 提供托管运行环境，降低团队自行部署和维护运行时的成本。
- Copilot 与 Claude Agent SDK 连接器让现有 Agent 能力进入统一编排流程。
GA 在这里很关键。它意味着这些组件不再只是用于验证想法的预览能力，而是进入有正式支持预期的稳定发布阶段。不过，GA 不等于业务逻辑天然可靠：工具权限、数据边界和人工审批仍需由应用团队设计。
多 Agent 编排真正难在边界，而不是数量
稳定版编排模式让团队可以组合专门化 Agent，例如让一个 Agent 分析工单，另一个查询资产，第三个生成处理建议。但生产系统不应让多个 Agent 随意互相调用。更稳妥的做法是为每个角色定义输入、输出和权限，并由编排器控制状态流转。
例如，一个运维工单流程可以拆成三步：
triage只读取工单并输出结构化分类。investigator只能调用只读监控和资产工具。executor涉及变更时必须等待人工批准。
这样的拆分可以缩小单个 Agent 的权限，也能在审计日志中回答“哪个角色基于什么输入作出了什么决定”。反过来，如果所有 Agent 共享同一组高权限凭据，即使编排图看起来很清晰，治理仍然只是表面工作。
可以这样实践：先把运行策略写成配置
下面是一个可直接改造的最小示例。这是基于摘要所体现的平台方向设计的通用配置，并非 Microsoft 产品配置格式。 它适合在接入实际 Harness API 前验证权限、超时、重试和人工审批边界。
将以下内容保存为 agent-policy.yaml：
version: 1
workflow: incident-response
runtime:
timeout_seconds: 120
max_steps: 8
retries: 1
agents:
triage:
connector: github-copilot
tools:
allow:
- ticket.read
output_schema: incident_classification
investigator:
connector: claude-agent-sdk
tools:
allow:
- metrics.read
- assets.read
output_schema: investigation_report
executor:
connector: internal-change-agent
tools:
allow:
- change.create
approval:
required: true
approver_group: sre-oncall
telemetry:
trace_inputs: true
trace_tool_calls: true
redact:
- authorization
- customer_email
接着可以用下面的 Python 脚本检查关键治理规则。脚本只依赖 PyYAML，不调用任何未在摘要中说明的 Microsoft API，因此可以直接运行：
python -m venv .venv
. .venv/bin/activate
python -m pip install pyyaml
Windows PowerShell 使用：
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install pyyaml
将检查器保存为 validate_policy.py：
from pathlib import Path
import sys
import yaml
policy = yaml.safe_load(Path("agent-policy.yaml").read_text(encoding="utf-8"))
errors = []
runtime = policy.get("runtime", {})
if runtime.get("timeout_seconds", 0) <= 0:
errors.append("runtime.timeout_seconds must be greater than zero")
if runtime.get("max_steps", 0) > 20:
errors.append("runtime.max_steps must not exceed 20")
for name, agent in policy.get("agents", {}).items():
allowed = set(agent.get("tools", {}).get("allow", []))
mutating = {tool for tool in allowed if tool.endswith((".create", ".update", ".delete"))}
approval_required = agent.get("approval", {}).get("required", False)
if mutating and not approval_required:
errors.append(f"{name}: mutating tools require explicit approval")
redacted = set(policy.get("telemetry", {}).get("redact", []))
if "authorization" not in redacted:
errors.append("telemetry.redact must include authorization")
if errors:
print("Policy validation failed:")
for error in errors:
print(f"- {error}")
sys.exit(1)
print("Policy validation passed")
运行检查：
python validate_policy.py
接入真实 Agent Harness 时，可以保留这类平台无关策略，再编写适配层将 connector、工具白名单、审批要求和遥测设置映射到实际 SDK 或托管服务。这样做的价值是，治理规则不会散落在提示词、Agent 代码和部署脚本之中。
上线前应验证的四件事
权限是否按 Agent 分离。 不要因为多个 Agent 属于同一工作流，就让它们共享高权限身份。读取数据、提出建议和执行变更应使用不同授权范围。
失败是否可恢复。 编排流程需要明确哪些步骤可重试，哪些步骤必须保持幂等，哪些外部操作需要补偿。模型调用可以重试，并不代表支付、发信或基础设施变更也可以盲目重放。
追踪是否泄露敏感数据。 Harness 级遥测有助于定位工具调用和上下文传递问题，但提示词、工具参数及模型输出可能包含令牌、个人信息或业务机密。上线前应测试脱敏规则，而不是只检查日志是否生成。
连接器是否可以替换。 Copilot 和 Claude Agent SDK 连接器扩展了可用生态，但业务状态与供应商专属消息格式耦合过深，会提高迁移和降级成本。内部工作流最好使用稳定的结构化输入输出契约。
从小范围、可审计的工作流开始
Microsoft Agent Framework 进入 GA 后，团队评估它时不应只比较模型效果或 SDK 易用性。更重要的问题是：运行时能否执行统一策略，托管环境是否符合数据与网络要求，连接器能否纳入现有身份体系，以及每次 Agent 决策能否被追踪和复核。
适合率先迁移的是低风险、只读、结果可验证的流程，例如工单分类、知识检索和调查报告生成。涉及删除、付款、生产变更或对外通信的流程，应加入人工批准、幂等键和独立审计。Agent Harness 提供了平台基础，但可靠性仍来自清晰的权限边界、结构化契约和经过演练的失败处理。