自测与判别:把两套运行时用对地方

概念层(3.1)

1. Chat Client 负责"怎么连模型"(纯连接器);Agent 负责"用模型+工具完成一轮任务"(带指令的执行单元)。两者都不存历史。
2. 无状态。
3. 存在 AgentThread 里,不在 Agent 里。
4. 从函数签名(参数名、类型注解、默认值)加 docstring 自动生成。类型注解直接决定模型看到的参数类型。
5. 一次 run() 可能多次往返模型、多次执行工具,所以 token 成本和延迟可能远超"一问一答"的直觉,需要为循环设上限。
6. client-managed:历史在 thread 自身,放进可插拔的 ChatMessageStore(内存/Redis/Cosmos)。server-managed:历史在服务端,thread 只留远端 ConversationId。
7. MCP 已 GA;A2A 绑定仍是 preview。

原理层(3.2)

1. request/response(点对点、直接寻址)与 publish/subscribe(一对多、主题广播、解耦)。
2. 因为 agent 只依赖"发消息/收消息"接口,消息怎么投递由运行时封装。actor 模型把通信机制与业务逻辑解耦,单机/分布式两个运行时 API 一致,所以可互换。
3. 屏障是所有 executor 跑齐、统一推进的同步点,此刻图状态一致、可完整存档;只有一致快照才能安全恢复,所以检查点落在屏障处。
4. AgentChat 偏非确定(让 agent 自由对话/规划);Workflow 是确定性的(图 + 超步 + 类型边,执行可预测、可复现)。
5. Task Ledger 管已知事实 + 计划;Progress Ledger 管每个子任务的进度。停滞计数器超阈值 → 触发重规划(replan),重写 Task Ledger 的计划。
6. Python 与 .NET 的 agent 能进同一个 workflow 跨语言互操作——来自底层语言无关的 actor 运行时。
7. 叫 ChatAgent;反直觉变化:从"有状态"变成"无状态"(历史移到 thread),且默认多轮工具循环。

应用判别层(3.3)

1. AgentChat 模式 · Sequential。两步固定、无条件分支、不要求恢复/审计——上 Workflow 图引擎是过度工程。落在图 2.3 决策树第一个菱形的"否"侧、第二个菱形的"否"侧。
2. Workflow 图引擎。跨天 + 可中断恢复 + 审计 + 人工签字,正好对应超步检查点(恢复)、确定性(审计)、HITL(签字)。AgentChat 没有屏障检查点,崩了从头来、过程难审计,撑不起来。
3. client-managed + 外部 store(如 Redis),或 server-managed;不能放进程内存。多实例负载均衡下,下个请求可能换实例,内存里的 thread 就丢了。要么按会话 id 从外部 store 取回(client-managed),要么交服务端托管(server-managed)。
4. (a)Handoff——单向交给唯一一个专家;(b)GroupChat——多 agent 反复发言到共识;(c)Magentic——步骤未知、要 LLM Manager 动态规划。
5. 跨语言协作选 MAF——Python↔.NET 同一 workflow 是它独家的护城河。换成纯 Python、最快出 demo、不想绑云,选 CrewAI(role-based、几小时出原型、不绑 Azure);LangGraph 也可,但 CrewAI 更快。
6. (a)研究项目暂不迁——AutoGen 仍是前沿研究路径,且维护模式无硬性下线日期,没有新企业需求就没有迁移收益;(b)生产原型该迁——可观测、可恢复、Workflow 检查点正是 MAF 相对 AutoGen 的增量,这正是迁移收益所在。