Agent 框架到底替你管理什么

框架解决重复的工程问题

你可以只用函数、循环和数据结构写出 Agent。框架的价值不是让系统突然“拥有智能”，而是把许多项目都会遇到的基础设施做成可组合能力：

• 连接不同模型与工具；
• 在步骤之间传递消息和状态；
• 组织顺序、并行、条件与交接；
• 统一处理错误、取消和资源上限；
• 记录调用、耗时与结果；
• 支持测试、评估和部署。

框架缩短的是工程路径，不替你决定产品目标、工具权限、数据边界或何时必须人工确认。

五个稳定职责

1. 决策

读取目标、状态与可用动作，提出下一步。真实系统中通常由模型参与；本课程用确定性规则模拟。

2. 工具

执行窄而可预测的工作。一个好工具有明确名称、用途、类型化输入、可检查输出和失败表示。

3. 状态

保存当前任务需要的事实、尝试和观察。状态应能序列化、检查和迁移，而不是散落在提示字符串里。

4. 编排

控制顺序、分支、并行、重试、暂停和停止。它是控制流，不是模型的同义词。

5. 观测

记录“何时、由谁、用什么输入、得到什么输出、花了多久、为何继续或停止”。日志是原料，能还原一次任务才叫可观测。

框架边界比框架品牌更重要

官方课程比较 Microsoft Agent Framework 与 Microsoft Foundry Agent Service 等能力。具体产品会演进，但下面的判断长期有效：

选择时先问“我的系统需要哪些职责、谁来承担”，再问“哪个产品实现这些职责”。反过来从产品名出发，容易把示例配置误当成架构。

为 Course Helper 画骨架

学习目标
   ↓
编排器 ──→ 决策器
   │          │
   │          ↓
   ├──────→ 工具
   │          │
   ↓          ↓
  状态 ←── 观察结果
   │
   └──────→ Trace

每个方框都应有独立输入、输出和测试。更换模型不应迫使你重写课程索引；更换存储不应改变工具契约；加入观测不应改变业务结果。

常见误区

• 框架就是 Agent：框架提供容器与能力，Agent 行为来自目标、工具、状态和边界的组合。
• 接上更多插件就更强：更多权限意味着更大攻击面与选择负担。
• 提示词里写了错误处理就够：超时、取消、重试与最大轮数必须由运行时保证。
• 先选平台再定义问题：会让产品能力反过来塑造错误需求。

本课完成定义

你应能在不提任何 SDK 名称的情况下解释一个 Agent 框架；把一次 Course Helper 请求标注为决策、工具、状态、编排与观测；并指出哪些判断必须由你的产品而不是框架做出。

本课依据锁定版本的探索 AI Agent 框架重构。