2025-01-20，DeepSeek 发布并开放 DeepSeek-R1 系列模型、论文与蒸馏模型权重。它让更多团队可以直接研究、部署和改造推理模型，而不只通过封闭 API 观察输出。 三个现实变化 推理过程研究门槛降低 开放模型与论文让研究者能够检查训练方法、复现实验、比较蒸馏效果，并在自己的评测集上研究推理能力与失败模式。 本地与私有部署选择增加 不同规模的蒸馏模型让团队可以在本地硬件上尝试推理工作负载。不过“能运行”不等于质量、速度和总成本适合生产，仍要用自己的任务评测。 模型能力不等于系统可靠性 更强推理仍可能产生错误事实、冗长过程、工具误用和提示注入风险。生产系统还需要权限、验证、状态管理、超时、成本控制和人工接管。 使用开放权重时要额外记录 模型具体变体、量化方式、推理引擎、上下文设置、采样参数、硬件与许可证。不同部署组合可能让同名模型表现明显不同。 一手来源： https://github.com/deepseek-ai/DeepSeek-R1 https://arxiv.org/abs/2501.12948 编辑说明：本文按 2025-01-20 的官方发布记录整理，并于 2026-08-15 核对仓库与论文页面。AI 协助起草，项目负责人复核。

2025-04-09，Google 公布 Agent2Agent（A2A）协议，目标是让不同厂商、不同框架构建的 Agent 能发现彼此能力、协商任务、交换消息并跟踪长期任务状态。 它面对的问题 当一个采购 Agent、供应商 Agent 和物流 Agent 来自不同系统时，单纯共享一个工具调用格式并不够。参与方需要知道对方能做什么、如何发送任务、任务是进行中还是等待输入，以及结果以什么形式返回。 A2A 引入 Agent Card、任务、消息和工件等概念，试图给跨 Agent 协作一个共同协议层。 与 MCP 的关系 可以粗略理解为：MCP 更关注 Agent 如何连接工具与上下文，A2A 更关注独立 Agent 之间如何协作。两者可能组合使用，但解决层次不同，也都不会自动处理业务授权和信任。 仍需工程回答的问题 怎样验证对方 Agent 的身份与组织关系。 怎样限制它能看到的任务和数据。 谁对跨 Agent 的错误决定负责。 长任务如何取消、超时、补偿和审计。 协议兼容是否真的意味着语义一致。 对 COHAO 来说，跨 Agent 协作是后续能力，不是创世期前置条件。先把单个受限工具和人工接管做好，再谈 Agent 之间自治。 一手来源： https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ https://github.com/a2aproject/A2A https://a2a-protocol.org/ 编辑说明：本文按 2025-04-09 的公开发布解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。

2025-03-11，OpenAI 在发布构建 Agent 的新工具时开源了 Agents SDK。它延续了较轻量的编排思路，把 Agent、工具、交接、Guardrails 和 Tracing 放到一个可组合的运行模型里。 值得关注的不是“又一个框架” 追踪成为一等能力 复杂 Agent 的问题通常不在最终一句回答，而在中间选了什么工具、传了什么参数、在哪一步失败。Tracing 让团队有机会把这些步骤转成调试和评测证据。 交接有明确结构 不同 Agent 可以各自承担窄职责，再通过 handoff 转移任务。它比让一个万能 Agent 拥有所有工具更容易限制上下文和权限，但交接本身仍需测试，不能把责任一起丢掉。 Guardrails 不是完整权限系统 输入输出检查可以降低明显错误，却不能替代后端认证、对象所有权、幂等和人工确认。真正的工具权限仍应由业务系统决定。 什么时候不需要 如果任务只是一次模型调用加一个只读查询，普通函数和清晰日志可能已经足够。框架的价值要由真实工作流、可观测性和维护成本证明，而不是由示例代码长度证明。 一手来源： https://openai.com/index/new-tools-for-building-agents/ https://github.com/openai/openai-agents-python https://openai.github.io/openai-agents-python/ 编辑说明：本文按 2025-03-11 的发布背景解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。

2024-11-25，Anthropic 公布 Model Context Protocol（MCP），把它定义为连接 AI 助手与数据源、工具和开发环境的开放标准。它试图减少一种长期重复工作：每个模型应用都为每个外部系统单独写一套连接器。 它标准化了什么 服务端如何暴露资源、提示和工具。 客户端如何发现能力并发起调用。 本地进程和远程服务的连接方式。 工具描述、输入结构和结果返回的共同语言。 这使“支持某个数据源”更可能成为可复用的服务能力，而不是只存在于一个 Agent 框架里的私有适配器。 它没有自动解决什么 MCP 不会替你完成身份认证、对象所有权、租户隔离、高风险确认、幂等、审计和密钥管理。一个 MCP 工具即使协议完全正确，也可能拥有过宽权限，或被提示注入诱导执行错误动作。 对社区 Agent 的意义 COHAO 未来可以把“检查来源”“读取公开主题”“生成待审核草稿”等能力做成窄工具，并通过标准协议接入不同 Agent。但协议层之上仍要由后端确定身份、权限和操作范围；管理员、资金和角色修改不会因为使用 MCP 就变安全。 一手来源： https://www.anthropic.com/news/model-context-protocol https://modelcontextprotocol.io/ https://github.com/modelcontextprotocol 编辑说明：本文解读截至 2026-08-15，重点是协议边界，不代表对所有 MCP 实现的安全背书。AI 协助起草，项目负责人核验来源。