目录一、为什么需要 Harness二、MAF 里的 Harness 处在什么位置三、从 v1.4 实验能力到 v1.15 正式发布四、代码入口一行创建 Harness Agent五、这行代码背后集成了什么六、能力 1自动 Tool Calling Loop七、能力 2每次模型调用后持久化 History八、能力 3TodoProvider让 Agent 显式规划任务九、能力 4AgentModeProvider区分计划和执行十、能力 5Compaction上下文自动压缩十一、能力 6File Memory保存跨轮笔记和产物十二、能力 7File Access受控读写工作目录十三、能力 8Skills按需加载领域能力十四、能力 9Web Search服务支持时自动接入十五、能力 10Tool Approval安全审批十六、能力 11Telemetry内置可观测性十七、Harness 与 Workflow 的区别十八、适合哪些场景1. 研究型 Agent2. 文件 / 数据处理 Agent3. 编码助手或自动化工程 Agent4. 企业领域助手十九、为什么这次正式发布重要二十、一个更完整的业务示例二十一、一句话总结代码含义结语Agent 开发正在进入 Harness Engineering 阶段在讨论 AI Agent 时我们很容易先关注模型本身模型有多强、推理能力如何、工具调用是否准确、上下文窗口有多大。但一个 Agent 能不能稳定完成任务除了模型本身还取决于模型外面的运行系统。这个运行系统现在通常被称为Agent Harness。所谓 Harness可以理解为包在大模型外面的一整套执行外壳它负责给模型接工具、管理上下文、保存任务状态、维护计划与待办、处理权限审批、控制执行循环并把运行过程变成可观测、可恢复、可治理的系统。没有 Harness模型更多是在“回答”有了 Harness模型才有机会持续地“行动”。换句话说Harness 解决的不是“模型会不会思考”而是“模型如何在真实环境里安全、持续、可控地完成任务”。这也是为什么越来越多 Agent 工程实践开始强调Agent Model Harness。Microsoft Agent FrameworkMAF也对 Harness 这一概念进行了系统实现。2026 年 7 月 22 日微软在官方博客中宣布Microsoft Agent Framework Harness 正式发布开发者现在可以在 .NET 与 Python 中使用一个稳定的、batteries-included 的 Agent Harness把模型、工具、记忆、计划、审批、上下文管理和遥测组合成一个可运行的生产级 Agent。这也意味着MAF Harness 从早期 v1.4 时代的实验性能力走到了 v1.15 时代的正式发布阶段。它不再只是示例代码或 preview API而是 Microsoft Agent Framework 里面向生产 Agent 的核心抽象之一。参考资料The Microsoft Agent Framework Harness is now releasedAgent Harnesses | Microsoft LearnStep 6: Agent Harness | Microsoft LearnAgent Harness in Agent Framework一、为什么需要 Harness大模型本身只能生成文本。它可以回答问题、写计划、生成代码但如果要让它真正“做事”还需要一层外壳来处理这些问题它如何调用工具它如何拆解长期任务它如何记住已经做过什么它如何避免上下文爆掉它什么时候需要用户审批它失败后如何恢复它的执行过程如何观测这层外壳就是Agent Harness。Microsoft Learn 对 Harness 的定义非常直接Harness 是把语言模型变成实际 Agent 的脚手架它驱动 Agent 的循环执行模型请求的工具管理历史与上下文应用审批和安全策略并推动任务持续完成。换句话说Model 负责“想”Harness 负责“让它能持续、可控、可观测地做”。这也是为什么现在越来越多人讨论 “Agent Model Harness”。模型能力决定上限Harness 工程决定落地质量。二、MAF 里的 Harness 处在什么位置Microsoft Agent Framework 是微软面向生产级 AI Agent 的多语言框架主要支持 .NET 与 Python并可以接入 Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic、Ollama 等模型生态。从开发者视角看MAF 里有三类重要抽象Agents单个智能体负责接收输入、调用工具、生成响应。Harness一个开箱即用的“增强型 Agent 外壳”适合长任务、自主任务、文件任务、研究任务。Workflows显式编排多个 Agent 或函数适合类型安全路由、检查点、人类介入等确定性流程。所以 Harness 不是替代 Agent也不是替代 Workflow。它更像是一个“生产级 Agent 默认套件”当你不想从零手写工具循环、计划系统、上下文压缩、文件记忆、审批规则时可以直接使用 Harness。三、从 v1.4 实验能力到 v1.15 正式发布MAF Harness 的演进很有代表性。在早期 v1.4 阶段社区已经开始用 Harness 组合TodoProvider、AgentModeProvider、SubAgentsProvider、FileMemoryProvider等组件来验证本地 LLM 场景。但当时它仍然不是正式发布 API使用者需要接受后续 breaking changes 的风险。随后微软开始系统介绍 Agent Harness 的工程价值它是模型推理连接真实执行的层负责 shell、文件系统、审批流、长期上下文管理等能力。到了后续版本Python 与 .NET 逐步加入并完善HarnessAgent/create_harness_agent并推进 Todo、Agent Mode、Loop、File Memory、File Access、Skills、Tool Approval 等能力的组合。最终2026 年 7 月微软正式宣布 Agent Framework Harness 发布。官方博客对它的描述是一个稳定的、batteries-included 的 harness内置 loop、planning、memory、context management、approvals、telemetry能够把模型变成真正可以做事的 Agent。这条演进线说明一件事Harness 不再只是示例代码或实验模式而是 MAF 的核心开发范式之一。四、代码入口一行创建 Harness Agent以 C# 为例默认 Harness 的最小用法是这段代码看起来只是把chatClient包了一层但这层就是 Harness 的核心价值它不是一个普通 chat wrapper而是把 chat client 变成一个带有工具循环、计划状态、上下文管理、历史持久化、安全审批和可观测性的 Agent runtime。官方文档也明确说明Harness 是围绕 chat client 的 batteries-included agentic pipeline内部在 .NET 中基于ChatClientAgent在 Python 中基于Agent。五、这行代码背后集成了什么可以把理解成下面这组能力的组合上面这段是“概念展开代码”不是实际 API 链式调用。它的作用是说明默认 Harness 把过去需要开发者手写的一整套 Agent 运行时拼装成了一个标准 Agent。官方发布文章列出的默认能力包括 function invocation、per-service-call history persistence、compaction、todo 与 agent-mode providers、file memory、skills、web search、tool approval 和 telemetry。六、能力 1自动 Tool Calling Loop普通模型调用一般是但 Agent 场景里模型可能会说“我需要先读文件、再分析、再写报告。”如果没有 Harness你需要自己写循环Harness 默认集成的 function invocation 就是帮你维护这个循环模型请求工具Harness 执行工具工具结果进入上下文模型继续推理直到完成或达到迭代限制。这件事看起来简单但它是 Agent 与普通 Chatbot 的分界线Chatbot 主要回答Agent 可以行动。七、能力 2每次模型调用后持久化 History长任务最怕中途断掉。例如 Agent 已经搜索了 8 个网页、读了 3 个文件、生成了中间计划结果进程崩溃。如果没有 history persistence前面的工作就丢了。Harness 的AgentSession承担了跨轮状态容器的角色这里第二次调用仍然传入同一个session所以 Harness 可以保留前一轮的计划、todo、history 等状态。这也是为什么使用 Harness 时不应该把每次调用都当成无状态请求。Harness 的价值很大一部分来自 session。八、能力 3TodoProvider让 Agent 显式规划任务没有 todo 的 Agent 很容易“边想边忘”。Harness 默认集成TodoProvider让 Agent 可以把复杂任务拆成工作项这不是简单的 prompt 技巧而是 Harness 提供的状态化能力。Agent 可以根据 todo 推进任务也可以在任务过程中更新、完成或重排 todo。对长任务来说todo 的意义很大它把模型的“隐式思考”变成了可跟踪的工作状态。九、能力 4AgentModeProvider区分计划和执行复杂任务通常有两个阶段Harness 默认集成AgentModeProvider用于跟踪 plan / execute / custom mode。这让 Agent 不只是连续聊天而是可以在“规划”和“执行”之间切换更接近真实工作流。尤其在需要审批、需要输出可解释计划、需要长期执行的场景里mode tracking 很重要。十、能力 5Compaction上下文自动压缩长任务会不断把历史、工具结果、文件内容塞进上下文。没有压缩机制时Agent 很容易超过模型 context window。Harness 的 compaction 能力用于控制长工具循环中的上下文大小这也是长任务 Agent 的关键工程问题之一。如果没有 compactionAgent 可能在任务还没完成时就因为上下文窗口溢出而失败如果压缩策略太粗糙又可能丢失关键事实。Harness 的意义在于它把这个通用问题内置进运行时而不是让每个开发者从零实现。十一、能力 6File Memory保存跨轮笔记和产物File memory 解决的是“Agent 工作记忆”的问题。比如 Agent 在调研过程中可以保存它和聊天 history 不完全一样。History 是对话过程。File memory 更像 Agent 的工作笔记、草稿和中间产物。对于研究、写作、代码修改、数据分析等任务File memory 很有价值。它让 Agent 不必把所有东西都塞进上下文而是可以把稳定中间产物落到文件里在需要时再读取。十二、能力 7File Access受控读写工作目录文件访问适合数据分析、代码处理、报告生成等场景。例如Agent 可以读取输入文件分析后写出结果不过 File Access 也是安全风险最高的能力之一。生产环境里文件访问应该遵循几个原则只允许访问明确的 working directory。高风险写操作需要审批。不允许默认读取用户任意目录。删除、覆盖、执行文件等操作要更严格。可以在文章中用下面的概念代码说明重点不是具体属性名而是工程原则Harness 可以提供文件工具但文件访问必须被目录边界和审批策略约束。十三、能力 8Skills按需加载领域能力如果把所有领域知识都塞进 system prompt会导致 prompt 越来越大、越来越难维护。Harness 支持 Skills让能力以文件包形式存在Agent 可以在需要时发现并加载相关 skill而不是一开始把所有知识放进上下文。这类机制的好处是领域能力可以模块化维护。不同 Agent 可以复用同一组 skills。上下文更干净不必预加载所有说明。团队可以把最佳实践沉淀成可分发的能力包。十四、能力 9Web Search服务支持时自动接入研究类 Agent 需要获取当前信息。Harness 支持在底层推理服务提供 web search 能力时启用搜索这里 Agent 可以先制定 todo再调用 web search再整理结果。需要注意的是Web Search 并不是所有模型和所有服务都天然支持。它通常依赖底层 inference service 的能力。因此文章中可以写成当底层服务支持时Harness 可以把 Web Search 纳入 Agent 的工具与 grounding 流程。十五、能力 10Tool Approval安全审批真实 Agent 不能随便执行所有工具。比如下面这些操作就应该有审批Harness 集成 tool approval可以把高风险工具调用交给人类确认也可以对安全调用设置 “don’t ask again” 规则这个能力非常关键因为 Agent 的核心矛盾就是没有工具它只是聊天机器人工具太自由它又可能变成风险源。Tool approval 的作用就是在自主性和安全性之间建立一个可配置的边界。十六、能力 11Telemetry内置可观测性生产环境里的 Agent 不能是黑盒。你需要知道Harness 默认集成 OpenTelemetry方便把 Agent 的执行链路接入日志、trace 和监控系统。这对生产环境非常重要。因为 Agent 系统的失败往往不是单点失败而是模型、工具、上下文、权限、外部 API、用户输入共同作用后的链式问题。没有 telemetry很难定位问题。十七、Harness 与 Workflow 的区别很多人会问既然 MAF 已经有 Workflow为什么还需要 Harness可以这样区分Harness 更适合开放式任务目标明确但路径不完全确定例如“帮我调研一个技术方案并输出报告”。Workflow 更适合显式流程步骤、输入输出、路由规则相对确定例如“审核申请 → 调用系统 → 人工确认 → 发送通知”。换句话说Harness 给 Agent 自主空间Workflow 给系统确定性控制。实际项目里两者并不冲突。你可以把 Harness Agent 放进 Workflow也可以让 Workflow 触发 Harness 去完成某个开放式子任务。十八、适合哪些场景结合 Harness 的能力它尤其适合四类应用。1. 研究型 Agent例如让 Agent 围绕一个主题生成计划、拆分 todo、搜索资料、整理摘要、写报告。这里需要计划、搜索、长期上下文、文件输出正好是 Harness 的强项。2. 文件 / 数据处理 Agent例如读取一个目录里的 CSV、PDF、Markdown 或代码文件分析后生成结果。File access、approval、history persistence 都很重要。3. 编码助手或自动化工程 AgentCoding Agent 的关键不是“会不会写代码”而是能否安全读写文件、运行命令、保存中间状态、根据测试反馈迭代。Harness 正是在这个层面提供基础设施。4. 企业领域助手比如财务、法务、运营、客户支持场景。领域知识可以封装成 Skills审批策略控制敏感操作Telemetry 用于审计与优化。十九、为什么这次正式发布重要MAF Harness 正式发布的意义不只是多了一个 API而是微软把 Agent 工程里的通用底座标准化了。过去开发者做一个稍微复杂的 Agent往往要自己拼这些东西工具调用循环多步任务计划上下文压缩文件记忆工具审批会话持久化可观测性错误恢复长任务 loop这些都不是业务差异化能力却很容易决定系统是否可用。Harness 的价值就在于把这些“每个 Agent 都需要、每个团队都容易重复造”的底层能力收敛成默认实现。开发者只需要提供三件事剩下的 agentic runtime 能力由 Harness 默认处理。二十、一个更完整的业务示例假设我们要做一个“技术调研助手”它可以搜索资料、生成 todo、保存笔记并输出 Markdown 报告。业务代码大概可以写成这样这段业务代码没有手写工具调用 looptodo 状态plan / execute 模式history persistencecontext compactionfile memoryapprovaltelemetry但这些能力都可以由 Harness runtime 提供。这正是 Harness 的核心价值把通用 Agent 基础设施从业务代码里抽离出来。二十一、一句话总结代码含义可以用下面这句话总结这行代码的意义不是“创建一个聊天机器人”而是把一个普通IChatClient包装成一个生产级 Agent runtime它默认具备工具调用循环、历史持久化、上下文压缩、todo 计划、plan/execute 模式、文件记忆、技能加载、搜索增强、工具审批和 OpenTelemetry 可观测性。开发者只需要补充模型、业务指令和领域工具就可以开始构建长任务、自主执行型 Agent。如果要写得更工程化可以这样说Harness 把通用 Agent 基础设施从业务代码里抽离出来让开发者不用重复手写 loop、memory、planning、approval 和 telemetry而是把精力放在业务工具和领域能力上。结语Agent 开发正在进入 Harness Engineering 阶段MAF Harness 的发布说明Agent 开发正在从“拼模型调用”进入“设计运行系统”的阶段。早期我们关心的是用哪个模型Prompt 怎么写工具怎么接现在更关键的问题变成Agent 如何持续推进任务如何记忆如何压缩上下文如何安全行动如何观测如何失败恢复如何让人类只在关键点介入这些问题都属于 Harness Engineering。所以MAF Harness 的价值不只是让微软生态里的 Agent 更容易写而是给了开发者一个清晰信号生产级 Agent 的竞争点正在从单次推理能力转向模型外部运行系统的工程质量。从 v1.4 实验版本到 v1.15 正式发布MAF Harness 走过的是一条典型的 Agent 基础设施成熟路线先把模式跑通再把组件拆稳最后把通用能力封装成默认运行时。对开发者来说接下来写 Agent 时不妨换一个思路不要先问“这个模型能不能做”先问“我有没有给它一个足够好的 Harness让它能安全、持续、可观测地做”引入地址
.NET+AI | Harness | Harness 正式发布，一行代码，生产级 Agent 就绪
发布时间：2026/7/31 12:40:31
目录一、为什么需要 Harness二、MAF 里的 Harness 处在什么位置三、从 v1.4 实验能力到 v1.15 正式发布四、代码入口一行创建 Harness Agent五、这行代码背后集成了什么六、能力 1自动 Tool Calling Loop七、能力 2每次模型调用后持久化 History八、能力 3TodoProvider让 Agent 显式规划任务九、能力 4AgentModeProvider区分计划和执行十、能力 5Compaction上下文自动压缩十一、能力 6File Memory保存跨轮笔记和产物十二、能力 7File Access受控读写工作目录十三、能力 8Skills按需加载领域能力十四、能力 9Web Search服务支持时自动接入十五、能力 10Tool Approval安全审批十六、能力 11Telemetry内置可观测性十七、Harness 与 Workflow 的区别十八、适合哪些场景1. 研究型 Agent2. 文件 / 数据处理 Agent3. 编码助手或自动化工程 Agent4. 企业领域助手十九、为什么这次正式发布重要二十、一个更完整的业务示例二十一、一句话总结代码含义结语Agent 开发正在进入 Harness Engineering 阶段在讨论 AI Agent 时我们很容易先关注模型本身模型有多强、推理能力如何、工具调用是否准确、上下文窗口有多大。但一个 Agent 能不能稳定完成任务除了模型本身还取决于模型外面的运行系统。这个运行系统现在通常被称为Agent Harness。所谓 Harness可以理解为包在大模型外面的一整套执行外壳它负责给模型接工具、管理上下文、保存任务状态、维护计划与待办、处理权限审批、控制执行循环并把运行过程变成可观测、可恢复、可治理的系统。没有 Harness模型更多是在“回答”有了 Harness模型才有机会持续地“行动”。换句话说Harness 解决的不是“模型会不会思考”而是“模型如何在真实环境里安全、持续、可控地完成任务”。这也是为什么越来越多 Agent 工程实践开始强调Agent Model Harness。Microsoft Agent FrameworkMAF也对 Harness 这一概念进行了系统实现。2026 年 7 月 22 日微软在官方博客中宣布Microsoft Agent Framework Harness 正式发布开发者现在可以在 .NET 与 Python 中使用一个稳定的、batteries-included 的 Agent Harness把模型、工具、记忆、计划、审批、上下文管理和遥测组合成一个可运行的生产级 Agent。这也意味着MAF Harness 从早期 v1.4 时代的实验性能力走到了 v1.15 时代的正式发布阶段。它不再只是示例代码或 preview API而是 Microsoft Agent Framework 里面向生产 Agent 的核心抽象之一。参考资料The Microsoft Agent Framework Harness is now releasedAgent Harnesses | Microsoft LearnStep 6: Agent Harness | Microsoft LearnAgent Harness in Agent Framework一、为什么需要 Harness大模型本身只能生成文本。它可以回答问题、写计划、生成代码但如果要让它真正“做事”还需要一层外壳来处理这些问题它如何调用工具它如何拆解长期任务它如何记住已经做过什么它如何避免上下文爆掉它什么时候需要用户审批它失败后如何恢复它的执行过程如何观测这层外壳就是Agent Harness。Microsoft Learn 对 Harness 的定义非常直接Harness 是把语言模型变成实际 Agent 的脚手架它驱动 Agent 的循环执行模型请求的工具管理历史与上下文应用审批和安全策略并推动任务持续完成。换句话说Model 负责“想”Harness 负责“让它能持续、可控、可观测地做”。这也是为什么现在越来越多人讨论 “Agent Model Harness”。模型能力决定上限Harness 工程决定落地质量。二、MAF 里的 Harness 处在什么位置Microsoft Agent Framework 是微软面向生产级 AI Agent 的多语言框架主要支持 .NET 与 Python并可以接入 Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic、Ollama 等模型生态。从开发者视角看MAF 里有三类重要抽象Agents单个智能体负责接收输入、调用工具、生成响应。Harness一个开箱即用的“增强型 Agent 外壳”适合长任务、自主任务、文件任务、研究任务。Workflows显式编排多个 Agent 或函数适合类型安全路由、检查点、人类介入等确定性流程。所以 Harness 不是替代 Agent也不是替代 Workflow。它更像是一个“生产级 Agent 默认套件”当你不想从零手写工具循环、计划系统、上下文压缩、文件记忆、审批规则时可以直接使用 Harness。三、从 v1.4 实验能力到 v1.15 正式发布MAF Harness 的演进很有代表性。在早期 v1.4 阶段社区已经开始用 Harness 组合TodoProvider、AgentModeProvider、SubAgentsProvider、FileMemoryProvider等组件来验证本地 LLM 场景。但当时它仍然不是正式发布 API使用者需要接受后续 breaking changes 的风险。随后微软开始系统介绍 Agent Harness 的工程价值它是模型推理连接真实执行的层负责 shell、文件系统、审批流、长期上下文管理等能力。到了后续版本Python 与 .NET 逐步加入并完善HarnessAgent/create_harness_agent并推进 Todo、Agent Mode、Loop、File Memory、File Access、Skills、Tool Approval 等能力的组合。最终2026 年 7 月微软正式宣布 Agent Framework Harness 发布。官方博客对它的描述是一个稳定的、batteries-included 的 harness内置 loop、planning、memory、context management、approvals、telemetry能够把模型变成真正可以做事的 Agent。这条演进线说明一件事Harness 不再只是示例代码或实验模式而是 MAF 的核心开发范式之一。四、代码入口一行创建 Harness Agent以 C# 为例默认 Harness 的最小用法是这段代码看起来只是把chatClient包了一层但这层就是 Harness 的核心价值它不是一个普通 chat wrapper而是把 chat client 变成一个带有工具循环、计划状态、上下文管理、历史持久化、安全审批和可观测性的 Agent runtime。官方文档也明确说明Harness 是围绕 chat client 的 batteries-included agentic pipeline内部在 .NET 中基于ChatClientAgent在 Python 中基于Agent。五、这行代码背后集成了什么可以把理解成下面这组能力的组合上面这段是“概念展开代码”不是实际 API 链式调用。它的作用是说明默认 Harness 把过去需要开发者手写的一整套 Agent 运行时拼装成了一个标准 Agent。官方发布文章列出的默认能力包括 function invocation、per-service-call history persistence、compaction、todo 与 agent-mode providers、file memory、skills、web search、tool approval 和 telemetry。六、能力 1自动 Tool Calling Loop普通模型调用一般是但 Agent 场景里模型可能会说“我需要先读文件、再分析、再写报告。”如果没有 Harness你需要自己写循环Harness 默认集成的 function invocation 就是帮你维护这个循环模型请求工具Harness 执行工具工具结果进入上下文模型继续推理直到完成或达到迭代限制。这件事看起来简单但它是 Agent 与普通 Chatbot 的分界线Chatbot 主要回答Agent 可以行动。七、能力 2每次模型调用后持久化 History长任务最怕中途断掉。例如 Agent 已经搜索了 8 个网页、读了 3 个文件、生成了中间计划结果进程崩溃。如果没有 history persistence前面的工作就丢了。Harness 的AgentSession承担了跨轮状态容器的角色这里第二次调用仍然传入同一个session所以 Harness 可以保留前一轮的计划、todo、history 等状态。这也是为什么使用 Harness 时不应该把每次调用都当成无状态请求。Harness 的价值很大一部分来自 session。八、能力 3TodoProvider让 Agent 显式规划任务没有 todo 的 Agent 很容易“边想边忘”。Harness 默认集成TodoProvider让 Agent 可以把复杂任务拆成工作项这不是简单的 prompt 技巧而是 Harness 提供的状态化能力。Agent 可以根据 todo 推进任务也可以在任务过程中更新、完成或重排 todo。对长任务来说todo 的意义很大它把模型的“隐式思考”变成了可跟踪的工作状态。九、能力 4AgentModeProvider区分计划和执行复杂任务通常有两个阶段Harness 默认集成AgentModeProvider用于跟踪 plan / execute / custom mode。这让 Agent 不只是连续聊天而是可以在“规划”和“执行”之间切换更接近真实工作流。尤其在需要审批、需要输出可解释计划、需要长期执行的场景里mode tracking 很重要。十、能力 5Compaction上下文自动压缩长任务会不断把历史、工具结果、文件内容塞进上下文。没有压缩机制时Agent 很容易超过模型 context window。Harness 的 compaction 能力用于控制长工具循环中的上下文大小这也是长任务 Agent 的关键工程问题之一。如果没有 compactionAgent 可能在任务还没完成时就因为上下文窗口溢出而失败如果压缩策略太粗糙又可能丢失关键事实。Harness 的意义在于它把这个通用问题内置进运行时而不是让每个开发者从零实现。十一、能力 6File Memory保存跨轮笔记和产物File memory 解决的是“Agent 工作记忆”的问题。比如 Agent 在调研过程中可以保存它和聊天 history 不完全一样。History 是对话过程。File memory 更像 Agent 的工作笔记、草稿和中间产物。对于研究、写作、代码修改、数据分析等任务File memory 很有价值。它让 Agent 不必把所有东西都塞进上下文而是可以把稳定中间产物落到文件里在需要时再读取。十二、能力 7File Access受控读写工作目录文件访问适合数据分析、代码处理、报告生成等场景。例如Agent 可以读取输入文件分析后写出结果不过 File Access 也是安全风险最高的能力之一。生产环境里文件访问应该遵循几个原则只允许访问明确的 working directory。高风险写操作需要审批。不允许默认读取用户任意目录。删除、覆盖、执行文件等操作要更严格。可以在文章中用下面的概念代码说明重点不是具体属性名而是工程原则Harness 可以提供文件工具但文件访问必须被目录边界和审批策略约束。十三、能力 8Skills按需加载领域能力如果把所有领域知识都塞进 system prompt会导致 prompt 越来越大、越来越难维护。Harness 支持 Skills让能力以文件包形式存在Agent 可以在需要时发现并加载相关 skill而不是一开始把所有知识放进上下文。这类机制的好处是领域能力可以模块化维护。不同 Agent 可以复用同一组 skills。上下文更干净不必预加载所有说明。团队可以把最佳实践沉淀成可分发的能力包。十四、能力 9Web Search服务支持时自动接入研究类 Agent 需要获取当前信息。Harness 支持在底层推理服务提供 web search 能力时启用搜索这里 Agent 可以先制定 todo再调用 web search再整理结果。需要注意的是Web Search 并不是所有模型和所有服务都天然支持。它通常依赖底层 inference service 的能力。因此文章中可以写成当底层服务支持时Harness 可以把 Web Search 纳入 Agent 的工具与 grounding 流程。十五、能力 10Tool Approval安全审批真实 Agent 不能随便执行所有工具。比如下面这些操作就应该有审批Harness 集成 tool approval可以把高风险工具调用交给人类确认也可以对安全调用设置 “don’t ask again” 规则这个能力非常关键因为 Agent 的核心矛盾就是没有工具它只是聊天机器人工具太自由它又可能变成风险源。Tool approval 的作用就是在自主性和安全性之间建立一个可配置的边界。十六、能力 11Telemetry内置可观测性生产环境里的 Agent 不能是黑盒。你需要知道Harness 默认集成 OpenTelemetry方便把 Agent 的执行链路接入日志、trace 和监控系统。这对生产环境非常重要。因为 Agent 系统的失败往往不是单点失败而是模型、工具、上下文、权限、外部 API、用户输入共同作用后的链式问题。没有 telemetry很难定位问题。十七、Harness 与 Workflow 的区别很多人会问既然 MAF 已经有 Workflow为什么还需要 Harness可以这样区分Harness 更适合开放式任务目标明确但路径不完全确定例如“帮我调研一个技术方案并输出报告”。Workflow 更适合显式流程步骤、输入输出、路由规则相对确定例如“审核申请 → 调用系统 → 人工确认 → 发送通知”。换句话说Harness 给 Agent 自主空间Workflow 给系统确定性控制。实际项目里两者并不冲突。你可以把 Harness Agent 放进 Workflow也可以让 Workflow 触发 Harness 去完成某个开放式子任务。十八、适合哪些场景结合 Harness 的能力它尤其适合四类应用。1. 研究型 Agent例如让 Agent 围绕一个主题生成计划、拆分 todo、搜索资料、整理摘要、写报告。这里需要计划、搜索、长期上下文、文件输出正好是 Harness 的强项。2. 文件 / 数据处理 Agent例如读取一个目录里的 CSV、PDF、Markdown 或代码文件分析后生成结果。File access、approval、history persistence 都很重要。3. 编码助手或自动化工程 AgentCoding Agent 的关键不是“会不会写代码”而是能否安全读写文件、运行命令、保存中间状态、根据测试反馈迭代。Harness 正是在这个层面提供基础设施。4. 企业领域助手比如财务、法务、运营、客户支持场景。领域知识可以封装成 Skills审批策略控制敏感操作Telemetry 用于审计与优化。十九、为什么这次正式发布重要MAF Harness 正式发布的意义不只是多了一个 API而是微软把 Agent 工程里的通用底座标准化了。过去开发者做一个稍微复杂的 Agent往往要自己拼这些东西工具调用循环多步任务计划上下文压缩文件记忆工具审批会话持久化可观测性错误恢复长任务 loop这些都不是业务差异化能力却很容易决定系统是否可用。Harness 的价值就在于把这些“每个 Agent 都需要、每个团队都容易重复造”的底层能力收敛成默认实现。开发者只需要提供三件事剩下的 agentic runtime 能力由 Harness 默认处理。二十、一个更完整的业务示例假设我们要做一个“技术调研助手”它可以搜索资料、生成 todo、保存笔记并输出 Markdown 报告。业务代码大概可以写成这样这段业务代码没有手写工具调用 looptodo 状态plan / execute 模式history persistencecontext compactionfile memoryapprovaltelemetry但这些能力都可以由 Harness runtime 提供。这正是 Harness 的核心价值把通用 Agent 基础设施从业务代码里抽离出来。二十一、一句话总结代码含义可以用下面这句话总结这行代码的意义不是“创建一个聊天机器人”而是把一个普通IChatClient包装成一个生产级 Agent runtime它默认具备工具调用循环、历史持久化、上下文压缩、todo 计划、plan/execute 模式、文件记忆、技能加载、搜索增强、工具审批和 OpenTelemetry 可观测性。开发者只需要补充模型、业务指令和领域工具就可以开始构建长任务、自主执行型 Agent。如果要写得更工程化可以这样说Harness 把通用 Agent 基础设施从业务代码里抽离出来让开发者不用重复手写 loop、memory、planning、approval 和 telemetry而是把精力放在业务工具和领域能力上。结语Agent 开发正在进入 Harness Engineering 阶段MAF Harness 的发布说明Agent 开发正在从“拼模型调用”进入“设计运行系统”的阶段。早期我们关心的是用哪个模型Prompt 怎么写工具怎么接现在更关键的问题变成Agent 如何持续推进任务如何记忆如何压缩上下文如何安全行动如何观测如何失败恢复如何让人类只在关键点介入这些问题都属于 Harness Engineering。所以MAF Harness 的价值不只是让微软生态里的 Agent 更容易写而是给了开发者一个清晰信号生产级 Agent 的竞争点正在从单次推理能力转向模型外部运行系统的工程质量。从 v1.4 实验版本到 v1.15 正式发布MAF Harness 走过的是一条典型的 Agent 基础设施成熟路线先把模式跑通再把组件拆稳最后把通用能力封装成默认运行时。对开发者来说接下来写 Agent 时不妨换一个思路不要先问“这个模型能不能做”先问“我有没有给它一个足够好的 Harness让它能安全、持续、可观测地做”引入地址
