我的 Agent System 看起来很强大，但实际上只是工业垃圾
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求保留源链接、保持原有的 Markdown 格式并将文本翻译成简体中文。
这篇周末笔记来得有点晚，因为我的 Deep Data Analyst 项目第一阶段暂时失败了。这意味着我无法继续之前承诺的 Data Analyst Agent 教程。
发生了什么？
我实际上构建了一个基于 ReAct 模式的 单代理数据分析助理。
该助理能够：
- 接收用户的分析请求。
- 形成一个合理的假设。
- 对上传的数据集进行 EDA（探索性数据分析）和建模。
- 提供专业的业务洞察和可操作的建议。
- 创建图表来支撑其观点。
如果你想看看它的实际效果，这里有一张截图：
说到底，这只是一个 单代理应用——并不难构建。如果你还记得，我曾解释过如何使用 ReAct 代理来解决 Advent of Code 挑战。这里是那篇教程：
How I Crushed Advent of Code And Solved Hard Problems Using Autogen Jupyter Executor and Qwen3
只要稍微调整一下该代理的提示词，你就可以获得我所说的同类数据分析能力。
为什么说它是一次失败？
因为我的代理和大多数 AI 爱好者构建的代理一样，非常适合用来向老板炫耀一个漂亮的原型，但一旦真实用户使用，它就会瞬间崩溃，沦为工业垃圾。
为什么这么说？
我的代理存在两个严重问题。
稳定性极差
这是我把它交给分析师用户后收到的最主要反馈。
如果你只尝试一次，它看起来非常惊艳。 它使用了普通分析师难以掌握的方法和技术，给出非常专业的论证。你会觉得用 AI 替代人类是你做过的最聪明的决定。
但数据分析本质上是 随时间检验因果关系。你必须每天或每周重复相同的分析，以验证助理的建议是否真的有效。
即使是相同的问题，代理 每次运行都会改变其假设和分析方法，从而每次给出不同的建议。这正是我所说的稳定性和一致性差。
想象一下，你让它使用 RFM 模型对用户进行细分并提供营销建议。
• 在一次活动之前，它使用特征 A、B、C，并为每个特征划分五个层级。
• 活动结束后，它突然加入了派生指标 D，现在在 A、B、C、D 上进行细分。
这样你根本无法正确进行 A/B 测试。
存在上下文‑位置偏差
如果你读过我之前的文章，你会知道我的 Data Analyst 代理是通过 基于有状态 Jupyter‑Kernel 的解释器 来运行代码的。
Exclusive Reveal: Code Sandbox Tech Behind Manus and Claude Agent Skills
这让代理能够像人类分析师一样工作：先提出假设，在 Jupyter Notebook 中运行代码进行验证，然后根据结果形成新的假设——不断迭代。
但问题在这里。过去的文章中我提到 LLM 在上下文位置上存在偏差……
处理长对话历史时的选择偏差：
Fixing the Agent Handoff Problem in LlamaIndex’s AgentWorkflow System
简而言之，LLM 并不会公平地对待每条消息。它们并不像我们预期的那样，根据最近性来加权重要性。
随着我们不断提出并测试假设，历史记录会不断增长。每条消息都很重要：
- 第一条消息展示了数据结构。
- 后面的消息推翻了某个假设，因此我们下次会跳过它。
所有信息都至关重要。然而，LLM 会开始关注错误的消息，而忽视已经纠正的内容，导致它重复错误。这要么浪费 token 和时间，要么把分析引向另一个话题——两者都不好。
因此，我的数据分析代理的第一阶段已经完成。
有什么办法可以修复吗？
构建具备原子技能的多代理系统
为了提高鲁棒性，你可能会考虑使用 上下文工程师 在分析开始 之前 锁定计划和度量定义。
当分析效果良好时，我们应当 将计划和先前的假设保存到长期记忆。
这两者都需要为代理 添加新技能。
但请记住，我的代理基于 ReAct，这意味着它的提示已经非常庞大——现在已经超过一千行。
…（原文的其余内容在此继续）
多代理数据分析师设计
添加任何新内容都有可能破坏这个脆弱的系统并扰乱提示的执行。
单一代理无法满足需求。我们需要将系统拆分为多个具备原子技能的代理，并对它们进行编排。
代理概览
| 代理 | 角色 |
|---|---|
| 问题澄清代理 | 向用户提问以澄清问题、确认指标并界定范围。 |
| 检索代理 | 从知识库中提取指标定义、计算方法和分析技术。 |
| 规划代理 | 提出假设，选择分析方法，并制定完整计划以保持下游代理的工作方向。 |
| 分析代理 | 将计划拆解为可执行步骤，运行 Python 代码，检验假设。 |
| 讲故事代理 | 将技术结果转化为引人入胜的业务故事和可操作的建议。 |
| 验证代理 | 确保整个过程正确、可靠且符合业务合规要求。 |
| 协调代理 | 管理所有代理，分配任务，并在它们之间路由消息。 |
Choose the Right Agent Framework
我们需要一个支持 消息传递 和 上下文状态保存 的框架：
- 当有新任务到达或代理完成时，应向 orchestrator 发送一条消息。
- orchestrator 也应通过消息来分配任务。
- 中间结果必须存储在共享上下文中，而不是每次都返回给 LLM（以避免位置偏差）。
Candidates
| Framework | Pros | Cons |
|---|---|---|
| LangGraph | 工作流定义简洁。 | 仍然基于我不喜欢的 LangChain。 |
| Autogen | 适合科研密集型任务；提供用于编排的 Selector Group Chat。 | 消息历史控制差，编排是黑盒，GraphFlow 不够成熟，开发已停滞。 |
| Microsoft Agent Framework (MAF) | 易于使用，具备现代特性（MCP、A2A、AG‑UI），工作流引擎稳健，支持上下文状态管理，具备 OpenTelemetry 可观测性，支持 switch‑case 与多选编排模式。 | 较新，社区资源仍在增长中。 |
Bottom line: 我将跳过 LangGraph 和 Autogen，直接使用 Microsoft Agent Framework (MAF)。
关于 Microsoft Agent Framework (MAF)？
我喜欢 MAF，因为它：
- 融合了早期框架的最佳理念，同时避免了它们的缺陷。
- 与 Qwen‑3 和 DeepSeek 模型配合良好（参见我关于结构化输出兼容性的指南）。
- 提供强大的 Workflow 功能：多种节点类型、内置上下文状态、可观测性以及灵活的编排模式。
“MAF 显得雄心勃勃。凭借 MCP、A2A、AG‑UI 等新能力以及微软的强力支持，它的长期前景应当比 Autogen 更好。”
参考文献：
Make Microsoft Agent Framework’s Structured Output Work With Qwen and DeepSeek Models
我的下一步
- 阅读 MAF 的用户指南和源代码 以熟悉其 API。
- 开始构建使用 MAF 的代理系统，将 Qwen‑3 和 DeepSeek 作为底层大语言模型集成。
- 将 Deep Data Analyst 架构适配到新框架（需要进行一些重构）。
- 探索 MAF 中的 Workflow 模式，了解它们如何映射到常见的 AI‑agent 设计模式。
多代理系统的优势在于增量式进展：我可以一步一步添加技能，并在它们准备好后立即分享更新，而不必等到整个项目完成。 😂
加入讨论
你感兴趣的是什么？ 在下方留下评论。
订阅 我的新闻通讯 Mr.Q’s Weekend Notes，获取最新的代理研究，直接发送到你的收件箱。
将此博客分享给朋友——也许它能帮助更多人。
喜欢这篇阅读吗？立即订阅，获取更多前沿数据科学技巧！ 欢迎你的反馈和提问——在评论中讨论吧！
本文最初发布于 Data Leads Future.