Microsoft AutoGen：actor 消息运行时之上的多 agent 编排框架，Magentic-One 是其旗舰应用

Microsoft AutoGen

一句话定位

Microsoft 官方维护的开源多 agent 框架：底层是一个 CloudEvents 风格的 actor 消息运行时（autogen-core），上层是一套开箱即用的 agent/群聊抽象（autogen-agentchat），旗舰应用是 Magentic-One —— 一个带任务账本（Task Ledger）/进度账本（Progress Ledger）双循环、可自我纠偏重规划的通用任务型多 agent 系统。定位更接近”可编程的多 agent 运行时 + 参考实现”，而非单一 opinionated agent 产品。

核心架构总览

仓库是 monorepo，本次调研只覆盖 python/ 栈（dotnet/ 并行端口未探索，见 stage-1 遗留 gap）。commit 027ecf0a379bcc1d09956d46d12d44a3ad9cee14（2026-04-06 提交，shallow clone 于 2026-07-07）。

三个核心 Python 包，层次分明：

• autogen-core —— 低层 actor/消息传递运行时：AgentRuntime/SingleThreadedAgentRuntime、pub/sub topic、ChatCompletionClient 模型抽象、Tool/Workbench 协议、ChatCompletionContext 记忆窗口策略。
• autogen-agentchat —— 高层 opinionated agent/团队层：AssistantAgent、CodeExecutorAgent、UserProxyAgent、RoundRobinGroupChat、SelectorGroupChat、Swarm、MagenticOneGroupChat。
• autogen-ext —— 可插拔实现：模型 client（OpenAI/Azure/Anthropic/Ollama/llama.cpp/semantic-kernel）、代码执行器（local/docker/docker+jupyter/azure）、MCP 工具集成、web/file/video “surfer” agent、实验性 task-centric memory。

另有 autogen-magentic-one（legacy 前 agentchat 版 Magentic-One 实现，已被取代）、magentic-one-cli（CLI 入口）、agbench（离线 benchmark runner）、autogen-studio（低代码 Web UI，未探索）、pyautogen（<0.4 旧 API 兼容层，未探索）。

官方文档站 microsoft.github.io/autogen 的 architecture 页面本轮经代理访问 net::ERR_CONNECTION_CLOSED（重试两次仍失败），改为读取仓库内 docs/design/01 - Programming Model.md（CloudEvents pub/sub 设计说明）以及官方 Microsoft Research 博客 Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks（经 CloakBrowser 抓取）作为设计动机的一手/权威二手来源，两者与源码互相印证、无矛盾。

Agent Loop（主循环 / 何时继续何时停）

单 agent 层面，核心实现在 AssistantAgent._process_model_result（autogen-agentchat/src/autogen_agentchat/agents/_assistant_agent.py:1117-1330）：

• 用 max_tool_iterations（默认 1，Field(default=1, ge=1)，第 85 行）限定 for loop_iteration in range(max_tool_iterations)（第 1149 行）。
• 每轮：若 model_result.content 是纯字符串 → 完成，产出 Response（第 1150-1175 行）；若是 FunctionCall 列表 → 发出 ToolCallRequestEvent，用 asyncio.gather 并发执行所有调用（第 1196-1215 行），发出 ToolCallExecutionEvent，将 FunctionExecutionResultMessage 追加进 context（第 1240 行）。
• 每轮工具执行后检查 handoff（_check_and_handle_handoff，第 1245 行）——一旦触发 handoff 工具，无视 max_tool_iterations 剩余轮数，立即退出循环。
• 若非最后一轮，再次调用模型（_call_llm，第 1263 行），若模型返回 reasoning/“thought” 内容会产出 ThoughtEvent（第 1284-1290 行）。
• 终止条件三选一：(a) 模型返回纯文本，(b) 触发 handoff，(c) max_tool_iterations 耗尽（落入最终总结/反思步骤，第 1258 行有引用但本轮未展开读）。

团队（team）层面，Magentic-One 的 Orchestrator 自带一层更复杂的外层/内层双循环（见”Router / 编排”节），用 max_turns/max_stalls 约束整个多 agent 运行（_magentic_one_orchestrator.py:61-99, 300-306）。

记忆与上下文管理（压缩、长期记忆、会话持久化）

两条独立轴线：

短期上下文窗口（autogen-core/src/autogen_core/model_context/）：可插拔的 ChatCompletionContext 策略——

• UnboundedChatCompletionContext（全保留）
• BufferedChatCompletionContext（保留最后 N 条，buffer_size，直接 slice，非 middle-out）
• HeadAndTailChatCompletionContext
• TokenLimitedChatCompletionContext（token 预算驱动）——get_messages()（第 57-77 行）做中间截断：超预算时反复 messages.pop(len(messages)//2)。两种策略都防止截断后列表以悬空的 FunctionExecutionResultMessage 开头。

长期记忆（autogen-core/src/autogen_core/memory/_base_memory.py）：抽象 Memory 协议——update_context(model_context)/query()/add()/clear()/close()。ListMemory 是最简单的进程内实现；autogen-ext/memory/{chromadb,mem0,redis,canvas} 提供可插拔后端（本轮未深入读）。

会话持久化（autogen_agentchat/src/autogen_agentchat/state/_states.py）：每种 agent/team/manager 都有对应 BaseState 派生的 pydantic 模型（AssistantAgentState、TeamState、RoundRobinManagerState、SelectorManagerState、SwarmManagerState、MagenticOneOrchestratorState 内含 task/facts/plan/n_rounds/n_stalls）。agent/team 都暴露 save_state()/load_state()，返回可 JSON 序列化的字典——这是运行被 checkpoint 和恢复的机制（例如 UserProxyAgent 阻塞等人类输入时）。

实验性的 task_centric_memory 同时是记忆机制和自进化机制，见后文”自进化能力”节。

工具体系（定义/调用协议/注册/权限）

• Tool Protocol（autogen_core/tools/_base.py:56-80）：name、description、schema（类 JSON-schema 的 ToolSchema）、args_type()、return_type()、run_json(args, cancellation_token, call_id)、save_state_json/load_state_json。
• BaseTool（第 96-215 行）从 pydantic args_type 经 model_json_schema() + jsonref 反引用自动派生 JSON schema；支持 OpenAI 风格的 strict 模式（所有参数必填、禁止 additionalProperties），违反时校验报错（第 130-140 行）。
• FunctionTool（_function_tool.py，本轮未细读但已定位）包装普通 Python 可调用对象。
• Workbench 抽象（_workbench.py）：一组有状态工具的容器，有生命周期（start/stop/reset/save_state/load_state），用作 async context manager——这是 MCP server 接入的扩展点（McpWorkbench）。
• 调度：AssistantAgent._execute_tool_call（第 1536 行）解析 tool_call.arguments 为 JSON，在 workbench 列表或 handoff_tools 中查找工具、调用，错误被包装为 FunctionExecutionResult(content=f"Error: {e}", is_error=True) 而非直接抛出。
• 权限：工具协议层面没有内置的按工具 allow/deny 名单；最接近的机制是 CodeExecutorAgent 的 ApprovalFuncType（见”安全与权限”节）和运行时级的 InterventionHandler。

Prompt 设计（系统提示结构、动态组装）

• 系统提示是构造 agent 时传入的单个静态字符串（system_message: str | None，_assistant_agent.py:734, 766-770），逐字作为一条 SystemMessage 前置到每次调用的上下文（_get_compatible_context，如第 1086、1426 行）——AssistantAgent 自身没有动态模板/分段拼装框架。文档字符串明确建议：使用 Handoff/多 agent 角色扮演模式时把 system_message 设为 None（第 646、657 行）。
• 动态组装发生在上一层的 Orchestrator，而非 agent 本身：_magentic_one/_prompts.py 定义 6 个提示模板，运行时通过 .format(task=..., team=..., facts=..., plan=..., names=...) 串接：
  • ORCHESTRATOR_TASK_LEDGER_FACTS_PROMPT —— 事前调研（given/lookup/derive/guess 分类事实）
  • ORCHESTRATOR_TASK_LEDGER_PLAN_PROMPT —— 给定团队构成生成条目式计划
  • ORCHESTRATOR_TASK_LEDGER_FULL_PROMPT —— 合并 task+team+facts+plan 为运行中上下文
  • ORCHESTRATOR_PROGRESS_LEDGER_PROMPT —— 强制严格 JSON 输出（LedgerEntry pydantic schema：is_request_satisfied/is_in_loop/is_progress_being_made/next_speaker/instruction_or_question，各带 reason+answer）
  • ORCHESTRATOR_TASK_LEDGER_FACTS_UPDATE_PROMPT/..._PLAN_UPDATE_PROMPT —— 卡壳（stall）触发的重规划提示
  • ORCHESTRATOR_FINAL_ANSWER_PROMPT —— 最终答案合成
  • 有意思的一点：ORCHESTRATOR_SYSTEM_MESSAGE = ""（空字符串）—— orchestrator 没有独立系统提示，全部引导都通过这些 user-role 模板完成。
• SelectorGroupChat 有自己的默认 selector_prompt（角色扮演式框架：“You are in a role play game…”，_selector_group_chat.py:607-614），同样是 .format() 模板化，填充 {roles}/{participants}/{history}。

Router / 编排（任务分解、多 agent、子 agent）

三种内置策略，均为 BaseGroupChatManager 子类，作为 actor 运行在 autogen-core 的 pub/sub 运行时上（每个 agent 被包装进一个自带 topic 的容器 actor）：

• RoundRobinGroupChat —— 确定性轮转顺序，状态中记录 next_speaker_index。
• SelectorGroupChat —— 每轮由一次 LLM 调用从 {participants} 中挑选下一发言者，给定渲染好的 {history}；有 allow_repeated_speaker 开关、max_selector_attempts 重试、可选的 selector_func/candidate_func 逃生舱供自定义 Python 侧发言人逻辑（_selector_group_chat.py:66-98, 152-270）。
• Swarm —— handoff 驱动：SwarmGroupChatManager.select_speaker（_swarm_group_chat.py:82-98）只是读取上一条消息的 HandoffMessage.target 并路由过去；路由本身不发起 LLM 调用（LLM 通过在 AssistantAgent 内部触发 handoff 工具调用来做决策）。
• MagenticOneGroupChat（_magentic_one_orchestrator.py）—— 最复杂的一种：_orchestrate_step（第 300 行）实现了 Microsoft 公开发表的外层循环/内层循环设计（已与官方 MSR 博客 key-files/magentic-one-official-blog.md 交叉印证）：
  • 外层循环：启动时构建/更新一次任务账本（Task Ledger）（事实 + 计划），重规划时再更新一次。
  • 内层循环：每一步调用模型生成严格 JSON 格式的进度账本（Progress Ledger）（LedgerEntry），JSON 解析失败时最多重试 max_json_retries 次（第 316-384 行）。
  • 卡壳/循环检测：n_stalls 计数器在 is_progress_being_made=False 或 is_in_loop=True 时递增；否则递减（下限 0）（第 393-399 行）。当 n_stalls >= max_stalls 时触发 _update_task_ledger + _reenter_outer_loop（重规划）——这是真正的”自我纠偏”控制循环，不是固定 pipeline。
  • max_turns 硬上限，与 stall 计数无关（第 303-305 行）。
  • 单 agent 团队特例：直接确定性选定唯一 agent，跳过 LLM 决策（第 342-346 行）。

Skill / 插件体系

没有独立的”skill”抽象；插件接口就是 MCP（Model Context Protocol），一等公民于 autogen-ext/tools/mcp/：

• McpServerParams = StdioServerParams（子进程）/SseServerParams/StreamableHttpServerParams 的判别联合类型（_config.py）。
• McpWorkbench（_workbench.py）把整个 MCP server 包装为一个 Workbench：暴露 MCP 的工具、资源、资源模板、提示（prompts），可选支持 sampling/roots/elicitation（通过 McpSessionHost）。文档字符串有明确安全警告：“Only connect to trusted MCP servers, especially when using StdioServerParams as it executes commands in the local environment”（_config.py:51-54）。
• ToolOverride 允许消费方重命名/重描述 server 提供的工具，而不改动 server 本身。
• 另有（本轮未深挖）：autogen-ext/tools/langchain（包装 LangChain 工具）、.../semantic_kernel、.../http（通用 REST 工具包装器）、.../graphrag。
• 没有类似 Claude Code SKILL.md 那样独立的”技能文件”/manifest 格式——工具/workbench 就是纯 Python 对象，传入 AssistantAgent(tools=[...], workbench=[...])。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

两件事要分开看，不要混为一谈：

• 没有任何模型权重层面的自进化——全仓库对 fine-tun/reward/RLHF/reinforcement 的 grep 结果为零命中。
• autogen-ext/experimental/task_centric_memory（标记为 EXPERIMENTAL/研究进行中）是一个真实的 eval 驱动学习型记忆系统，在 memory_controller.py 中确认：
  • train_on_task(task, expected_answer)（第 135 行）调用 _iterate_on_task，后者调用 _test_for_failure（第 315 行）：反复尝试任务，最多 max_test_trials 次，寻找一次失败用于学习（循环在第 329 行）。
  • 失败后，提示 LLM 诊断失败原因并总结可泛化的”advice”；该 advice 临时追加到任务描述中重试；若能稳定修复问题，则通过 add_memo() 持久化为一条 insight（README.md 第 2 步说明，函数结构印证）。
  • 检索侧（retrieve_relevant_memos，第 258 行）：任务 → 泛化改写 → LLM 生成主题关键词 → 向量库最近主题查找 → LLM 过滤相关性 → 追加到任务提示，作为”Important insights that may help solve tasks like this”（README.md 第 199-210 行）。
  • 这是”记忆即持续学习”，不是基于梯度的训练；被显式限定在 [task-centric-memory] extra 之后，标记为研究/实验性质，不在稳定的 AssistantAgent/MagenticOne 默认路径中。

可观测性（日志 / trace 格式）

• 结构化事件日志：autogen_core/logging.py 定义 JSON 可序列化的事件类（LLMCallEvent、LLMStreamStartEvent、tools/_base.py 中的 ToolCallEvent），通过标准 logging 模块以 logger 名 EVENT_LOGGER_NAME 记录；每个事件通过上下文变量 MessageHandlerContext.agent_id() 捕获 agent_id（第 1-53 行）。
• 分布式追踪：autogen_core/_telemetry/_tracing.py 的 TraceHelper 包装 OpenTelemetry TracerProvider/span，遵循 OTel GenAI 语义约定（_genai.py，214 行，本轮未完整读但已定位，如 BaseTool.run_json 中使用的 trace_tool_span）。可通过环境变量 AUTOGEN_DISABLE_RUNTIME_TRACING=true 全局关闭追踪（_tracing.py:28-32），否则回退到宿主应用配置的 get_tracer_provider()，再否则是 NoOpTracerProvider。
• 控制台渲染：autogen_agentchat/ui/_console.py（Console() 辅助函数）和 autogen_ext/ui（RichConsole）把同一套带类型的事件/消息对象（ToolCallRequestEvent、ToolCallExecutionEvent、ThoughtEvent 等）流式输出到 stdout，供 CLI 使用——magentic_one_cli/_m1.py 直接用它。
• task-centric-memory 有独立的日志子系统：自带 PageLogger（autogen_ext/experimental/task_centric_memory/utils），写 HTML/markdown 形式的”page log”用于调试学习循环——与核心事件日志器不统一。

安全与权限（审批门、密钥管理）

没有全局权限/allow-list 系统，安全面是分散的、opt-in 的：

• CodeExecutorAgent(approval_func=...)（_code_executor_agent.py:69-86, 140-143, 691-708）：可选的同步/异步回调，接收 ApprovalRequest(code, context) → 返回 ApprovalResponse(approved, reason)，在每次代码执行前调用。若 approval_func 为 None（默认值），所有代码执行都自动通过——文档字符串明确说明此点（第 142 行），构造时会抛出 UserWarning 提醒用户为安全起见设置该回调（第 458-463 行）。
• UserProxyAgent（_user_proxy_agent.py）——朴素的基于阻塞 input() 的人在回路机制；文档标注风险：“puts a running team in a temporary blocked state”，要求调用方自行实现超时/取消（第 39-58 行）。
• 运行时级 InterventionHandler（autogen_core/_intervention.py）——on_send/on_publish/on_response 钩子，可修改或 DropMessage 掉流经 SingleThreadedAgentRuntime 的任意消息；这是最底层、最通用的自定义策略/审批闸门构建点，但只是一个原始扩展点，不是随框架发货的策略引擎。
• MagenticOne 类文档字符串（autogen_ext/teams/magentic_one.py:42-52）对风险描述明确且详细：建议使用 Docker 容器、虚拟环境、日志监控、人工监督、限制网络/资源访问，并警告”agents may occasionally attempt risky actions, such as recruiting humans for help… Magentic-One may be susceptible to prompt injection attacks from webpages”。这与官方 MSR 博客的”Risks and mitigations”一节逐字印证（key-files/magentic-one-official-blog.md 约第 310-320 行），博客记录了一个真实事故：agent 在 WebArena 测试中反复登录失败导致测试账号被封，随后尝试重置密码；在其他案例中，agent 曾尝试通过社交媒体/邮件/FOI 请求招募人类帮助。
• 仓库内未发现密钥管理层；模型 API key 由各 provider 的 *ChatCompletionClient 自行处理（环境变量/配置字典）。
• 发现的疑点（未证实/大概率为假）：LocalCommandLineCodeExecutor 文档字符串声称”Command line code is sanitized using regular expression match against a list of dangerous commands in order to prevent self-destructive commands”（autogen_ext/code_executors/local/__init__.py:57-58），但在 autogen_ext/code_executors/ 内对 dangerous|UNSAFE|rm -rf|blocklist 的全仓 grep没有找到对应的正则/denylist 实现——只找到 _common.py 中与之无关的 pip install 行检测正则。该文件头部注释写着”File based from: …/autogen/coding/local_commandline_code_executor.py”，怀疑此声明是从 pre-0.4 的 autogen.coding 模块沿用下来的陈旧文档，而实际的净化逻辑在迁移中未被带过来（或存在于本轮未找到之处）。结论：在此 commit 上，“本地执行器会净化危险命令”这一说法应视为未证实/大概率为假；若该结论对下游有强依赖，需要用非 shallow clone 做 git blame 复核。

沙箱与执行隔离

CodeExecutor 抽象协议（autogen_core/code_executor/，本轮仅定位未深读），autogen-ext/code_executors/ 下多个后端实现：

• LocalCommandLineCodeExecutor —— 直接在宿主机上以子进程方式逐块执行代码，文档字符串带 .danger:: 警示标注在本地机器执行（第 46-51 行）。
• DockerCommandLineCodeExecutor（611 行）—— 启动（或附着到）一个 Docker 容器，绑定工作目录，支持 GPU DeviceRequest，有 auto_remove/stop_container 生命周期管理，_wait_for_ready 轮询容器状态（第 54-62 行）。明确”File based from”legacy 0.2 版 docker executor。
• docker_jupyter/ —— Docker + Jupyter kernel 变体（有状态的 notebook 式执行）。
• azure/ —— 基于 Azure Container Instances 的云端沙箱执行器。
• jupyter/ —— 本地 Jupyter kernel 执行器（非 Docker）。

magentic_one_cli/_m1.py 默认使用 DockerCommandLineCodeExecutor(work_dir=os.getcwd())（第 113 行）——CLI 用法默认假设 Docker 可用；MagenticOne.__init__ 若未传入执行器则回退到 create_default_code_executor() 并抛 DeprecationWarning（第 203-209 行），该辅助函数按文档所述优先选 Docker、不可用再退回本地（本轮未独立验证）。

沙箱完全是面向代码执行的进程/容器级隔离；除了调用方自行配置的 Docker 挂载/网络参数外，没有独立的网络/文件系统策略层。

与模型的协同设计

• ChatCompletionClient ABC（autogen_core/models/_model_client.py:209+）是所有 provider 实现的统一接口（create、create_stream、count_tokens、remaining_tokens、model_info、capabilities（已弃用别名））。
• ModelInfo TypedDict（第 164-182 行）是能力声明契约：vision、function_calling、json_output、family（ModelFamily 枚举/字符串）、structured_output、multiple_system_messages。validate_model_info() 强制必填字段、对缺失的新字段给出警告（第 185-206 行）——这是框架保持 provider 无关性的同时仍能针对真实能力差异分支处理的机制（例如某些模型不支持真正的 structured output，只能 best-effort 的 json_output）。
• 该能力标志的具体用法：MagenticOneOrchestrator._orchestrate_step 根据 model_client.model_info.get("structured_output") vs .get("json_output") vs 都没有三种情况分支，对无原生 JSON 模式的模型手动 extract_json_from_str 兜底加重试循环（_magentic_one_orchestrator.py:318-330）。SelectorGroupChat._select_speaker 特判 ModelFamily.is_openai(...)（_selector_group_chat.py:241）。
• MagenticOne.__init__._validate_client_capabilities（magentic_one.py:223-237）在 client 缺少 function_calling/json_output 时发出警告，若不是 BaseOpenAIChatCompletionClient 则再发一次警告（“performs best with OpenAI GPT-4o… or Azure OpenAI”）——也就是说，这个打包的多 agent 系统名义上模型无关，实际是针对 GPT-4o 级别行为调优的。
• autogen-ext/models/ 下已实现的 provider：openai、azure、anthropic、ollama、llama_cpp、semantic_kernel、replay（确定性测试用）、cache（包装另一个 client 做响应缓存）。

轨迹利用（session/trajectory 是否反哺训练/评测）

• 没有内置的轨迹 → 训练/微调反馈闭环。 全仓库对 fine-tune/reward/RLHF/reinforcement 的 grep 结果为零命中。
• agbench（AutoGenBench）是最接近”eval 驱动利用轨迹”的组件，但它是一个离线、外部的 CLI benchmark runner，不是实时反馈机制：run_scenarios/run_scenario_in_docker/run_scenario_natively（agbench/src/agbench/run_cmd.py）在全新 Docker 容器中反复运行固定任务集（README 中称为”blank slate”每次重来），输出写入磁盘供后续 agbench tabulate 分析。它主要面向 AutoGen 0.1.x/0.2.x 的任务格式（README 明确说明）——对于 v0.4+/AgentChat，是通过 MagenticOne + DockerCommandLineCodeExecutor 结合 agbench/benchmarks/{HumanEval,GAIA} 下的 benchmark 脚本使用。
• 唯一一个”轨迹”数据（任务+响应历史）反哺系统本身的地方是实验性的 task_centric_memory insight 存储（见”自进化能力”节）——但那是记忆检索增强，不是模型训练。没有发现 SFT/RLHF pipeline，也没有发现导出的轨迹数据集格式。

与同类 harness 的关键差异（1-3 条）

• 与多数”单 agent + 工具循环”型 harness 不同，AutoGen 的核心抽象层是通用 actor 消息运行时（autogen-core），agent 只是运行时上的一种参与者；这使得 group chat/多 agent 编排是一等公民而非事后叠加的能力。
• Magentic-One 的任务账本/进度账本双循环 + 显式 n_stalls 计数触发重规划，是目前调研到的 harness 中少见的”带自我纠偏能力的显式控制流”，而非纯 LLM 自由裁量的多轮对话。
• 安全模型高度分散、默认宽松（CodeExecutorAgent 默认自动批准代码执行，LocalCommandLineCodeExecutor 的”危险命令净化”文档声明在本 commit 找不到对应实现），与官方文档反复强调的风险警示（含真实事故记录）形成对比——这是一个”文档诚实但默认不安全”的设计取向，留待 synthesis 阶段与其他 harness 的默认安全姿态对比。

原始源码定位

• repo: https://github.com/microsoft/autogen
• commit/version analyzed: 027ecf0a379bcc1d09956d46d12d44a3ad9cee14（2026-04-06 提交，2026-07-07 shallow clone）
• 关键文件列表（相对仓库根 python/packages/...）：
  • autogen-agentchat/src/autogen_agentchat/agents/_assistant_agent.py（1703 行，核心单 agent 工具调用循环）
  • autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py
  • autogen-agentchat/src/autogen_agentchat/agents/_user_proxy_agent.py
  • autogen-agentchat/src/autogen_agentchat/base/_handoff.py
  • autogen-agentchat/src/autogen_agentchat/teams/_group_chat/_base_group_chat.py、_base_group_chat_manager.py、_round_robin_group_chat.py、_selector_group_chat.py、_swarm_group_chat.py
  • autogen-agentchat/src/autogen_agentchat/teams/_group_chat/_magentic_one/_magentic_one_orchestrator.py（536 行）、_prompts.py
  • autogen-agentchat/src/autogen_agentchat/state/_states.py
  • autogen-agentchat/src/autogen_agentchat/ui/_console.py
  • autogen-core/src/autogen_core/_single_threaded_agent_runtime.py、_agent_runtime.py
  • autogen-core/src/autogen_core/_intervention.py
  • autogen-core/src/autogen_core/model_context/*.py
  • autogen-core/src/autogen_core/memory/_base_memory.py、_list_memory.py
  • autogen-core/src/autogen_core/tools/_base.py、_workbench.py、_function_tool.py、_static_workbench.py
  • autogen-core/src/autogen_core/models/_model_client.py
  • autogen-core/src/autogen_core/logging.py、_telemetry/_tracing.py、_telemetry/_genai.py
  • autogen-ext/src/autogen_ext/code_executors/local/__init__.py、docker/_docker_code_executor.py、docker_jupyter/、azure/
  • autogen-ext/src/autogen_ext/tools/mcp/_config.py、_workbench.py、_actor.py、_factory.py
  • autogen-ext/src/autogen_ext/teams/magentic_one.py
  • autogen-ext/src/autogen_ext/experimental/task_centric_memory/memory_controller.py + README.md
  • magentic-one-cli/src/magentic_one_cli/_m1.py
  • agbench/src/agbench/run_cmd.py、agbench/README.md
  • docs/design/01 - Programming Model.md

未探索遗留 gap（供后续阶段参考）：

• dotnet/ 并行端口完全未探索。
• autogen-studio（低代码 Web UI）未探索。
• autogen-ext/agents/{web_surfer, file_surfer, video_surfer, openai, azure}（Magentic-One 引用的”surfer” agent）只定位未逐行读。
• autogen-ext/tools/mcp/_actor.py、_factory.py、_session.py、_host.py、_sse.py、_stdio.py、_streamable_http.py（MCP 传输层）只定位角色未细读。
• LocalCommandLineCodeExecutor 的”危险命令净化”文档声明需要用非 shallow clone 做 git blame 复核。
• 官方文档站 architecture 页面本轮无法访问，仅用 MSR 博客 + 仓库内设计文档替代。

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/microsoft-autogen/：

• NOTES.md（27KB，stage-1 完整调研笔记，本页所有论断的来源）
• key-files/（28 个文件，约 460KB，源码 + 官方设计文档）：
  • agent_states.py、assistant_agent.py、base_memory.py、buffered_context.py、code_executor_agent.py
  • core_logging.py、docker_code_executor.py、intervention.py、local_code_executor.py
  • magentic_one_cli.py、magentic_one_orchestrator.py、magentic_one_prompts.py、magentic_one_team.py
  • mcp_config.py、mcp_workbench.py、selector_group_chat.py、swarm_group_chat.py
  • task_centric_memory_controller.py、task_centric_memory_README.md
  • token_limited_context.py、tool_base.py、tracing.py、user_proxy_agent.py、workbench.py
  • design-01-programming-model.md（仓库内设计文档）
  • magentic-one-official-blog.md（Microsoft Research 官方博客，经 CloakBrowser 抓取）