从 A2A 到 MCP：为什么"上下文"决定 AI 代理的生产力
对话自然转向了另一个关键协议——A2A（Agent-to-Agent），这是 Google 实验室推出的通信框架。随着 AI 代理数量急剧膨胀，工具之间的互联互通需求也在爆发式增长：连接 10 个工具到 1 个代理已是不小的工作量，而当系统中存在 10 个甚至 10,000 个代理时，连接成本将变得难以承受。
A2A 与 MCP 解决的是同一个问题的两个侧面：MCP 负责上下文供给（让代理获得必要的企业数据），A2A 则进一步允许代理之间直接共享信息，从而将过去需要人类知识工作者完成的定制化配置工作卸载给机器。这是一个更具可扩展性的 AI 工具使用范式。
为什么"上下文"是代理能力的瓶颈
即便大语言模型本身的能力在近几年已有显著提升，它们依然无法天然访问企业的私有数据——你的内部文档、GDrive、M365 邮箱、笔记，都不在模型的训练语料中。代理在你自己的安全环境中工作，却对你的工作了如指掌，这是一个根本矛盾。
Stack Internal 的思路是：通过 MCP 服务器建立安全的企业上下文访问通道，让代理能够直接读取经过验证的企业数据，而不必依赖模型"开箱即用"的通用能力。代理因此可以在你的日常工作流中完成那些本就需要你亲自操作的任务。
安全顾虑：MCP 扩张路上的最大挑战
规模扩张带来了显著的安全焦虑。用链子来比喻——链子的强度取决于最薄弱的一环。当所有系统通过 MCP 或 A2A 框架互联时，一旦某个节点发生数据泄露或包含 PII（个人身份信息），风险就会沿着通信链路迅速蔓延，给企业造成巨大损失。
Stack Internal 的解决方案是每个用户都需要独立认证。以工程师为例，当他们通过 IDE 连接 MCP 服务器时，必须先用 OAuth2 登录自己的账号，之后才能建立从编码会话到底层平台的加密连接。OAuth2 作为行业标准的授权框架，确保数据在往返传输过程中始终保持安全可追溯，同时保留用户归属（attribution）记录。
Stack Internal 的 MCP 服务器有何不同
被反复提及的双向（bidirectional）特性与知识摄入（knowledge ingestion）能力，意味着 Stack Internal 的 MCP 服务器不仅是单向读取企业数据，还能将用户工作过程中的反馈、标注等增量知识写回知识库，形成持续更新的闭环。这是企业级 MCP 实现与通用方案的核心差异。
Stack Internal MCP 服务器：让知识库「活」起来
MCP 服务器（Model Context Protocol Server）并非只能做读取。在 Stack Internal 的实践中，一个被多数人忽视的能力是写回——将 AI 生成的解决方案直接推回知识库，保持内容的持续更新。
为什么需要专门的 MCP 服务器
Stack Internal 数据仓库积累了大量社区互动数据：用户提问、正确答案、评论更新、赞同与反对票。这些信号本身就是判断内容质量的依据。
一个内容可能获得大量投票，但已严重过时；另一个内容很新，但缺少足够的社区验证。如何在检索时综合权衡这些因素，正是 Stack 优化搜索的核心能力所在。直接接入 API 也能工作，但搜索效果远不及专门调校过的 MCP 服务器。
写回机制：知识库「常青」的秘诀
Stack Internal MCP 服务器支持双向操作：读取上下文 + 写回更新。
开发者无需离开 IDE 或 AI 编程工具，直接将找到的优质解决方案推送回 Stack Internal 数据仓库，沉淀为可复用的组织知识。这解决了文档维护中最常见的问题——人们不愿意在完成工作后额外花时间整理记录。
据 BM 在访谈中分享，当团队规模达到数千人时，文档更新不足是普遍现象。MCP 服务器让 AI 代理代为撰写 README 或文档并自动推送归档，实际使用频率几乎与读取功能持平。
连接方式：一次点击或几行代码
Stack 为主流开发工具提供一键安装入口，从官方 MCP 落地页即可完成连接。
若需自定义集成，只需一个 JSON 配置包，通过 OAuth2 完成身份验证后即可调用。门槛很低，关键是确保目标工具支持 MCP 协议——目前主流 AI 平台与编程助手均已默认支持。
评论