Posts

引言 2026年，Agent从单体应用走向微服务已经成为不可逆转的趋势。一个复杂的Agent系统可能包含意图识别服务、规划服务、工具执行服务、记忆服务等十几个微服务。如何设计、部署和管理这些Agent微服务，是每个AI工程团队面临的挑战。 本文将结合云原生最佳实践，探讨Agent微服务架构的设计要点。 一、Agent微服务拆分 1.1 拆分原则 按能力拆分：每个微服务对应一种核心能力。 意图识别服务：理解用户意图 规划服务：制定执行计划 工具执行服务：调用外部工具 记忆服务：管理Agent记忆 对话管理服务：管理多轮对话 安全审查服务：内容审核和安全检查 按变更频率拆分：频繁变更的部分独立为微服务，稳定部分合并。 工具执行服务变更频繁（新工具不断加入） 意图识别服务相对稳定 按团队拆分：不同团队负责的模块独立为微服务。 1.2 拆分粒度 过粗的拆分无法发挥微服务优势，过细的拆分增加管理复杂度。2026年的经验法则是：一个Agent微服务的职责应该能用一句话描述清楚。 1.3 数据隔离 每个微服务应该有自己的数据存储，不共享数据库。服务间通过API通信，不直接访问对方的数据。 Intent Service → Intent DB (Redis) Planning Service → Planning DB (PostgreSQL) Memory Service → Vector DB + Graph DB Tool Service → Tool Registry (etcd) 二、服务通信 2.1 同步通信 使用gRPC或HTTP/REST进行同步调用。适合需要实时响应的场景。 service IntentRecognitionService { rpc RecognizeIntent(IntentRequest) returns (IntentResponse); } message IntentRequest { string user_input = 1; string conversation_id = 2; map<string, string> context = 3; } message IntentResponse { string intent = 1; float confidence = 2; map<string, string> entities = 3; } 2.2 异步通信 使用消息队列进行异步通信。适合不需要实时响应的场景。 ...

Apple Intelligence 2.0：端侧AI的新标杆 2026年6月的WWDC 2026上，Apple发布了iOS 20和Apple Intelligence 2.0。如果说2025年的Apple Intelligence 1.0还是"小心翼翼的试水"，那么2.0版本则是一次全面进击——端侧3B参数语言模型、实时多模态理解、App级Agent框架，Apple正在用自己的方式定义移动AI。 端侧模型升级 3B参数语言模型 Apple Intelligence 2.0的核心是一个3B参数的端侧语言模型，运行在A19和M5芯片的Neural Engine上： 规格 AI 2.0模型 AI 1.0模型 参数量 3B 1.8B 架构 Transformer + MoE Transformer 量化 4-bit (INT4) 4-bit 模型大小 ~1.5GB ~900MB 推理速度 80 tokens/s 45 tokens/s 上下文 16K 4K 功能调用 原生支持 不支持 3B模型采用了MoE架构，8个专家中每次激活2个，等效计算量约2B参数但能力接近4B Dense模型。这使得它在保持快速推理的同时，能处理更复杂的任务。 多模态理解 端侧模型现在可以理解图像和文档： 图像理解：识别照片中的物体、场景、文字（OCR） 文档理解：解析PDF、截图中的结构化信息 屏幕理解：实时理解当前屏幕内容，提供上下文感知的AI辅助 所有多模态处理在设备端完成，不上传任何数据到云端。 私有云计算 对于需要更强算力的任务，Apple Intelligence 2.0使用"私有云计算"（Private Cloud Compute）： 端侧模型判断任务复杂度，超出端侧能力时自动切换到云端 云端使用更大模型（据称是7B参数），运行在Apple自研的M5 Ultra服务器芯片上 数据在请求完成后立即删除，不持久化存储 请求使用端到端加密，Apple也无法解密用户数据 Apple还引入了"Swift-Homomorphic"——基于同态加密的推理方案，使得云端在无法解密数据的情况下处理AI请求。虽然目前只支持简单任务，但这是端到端隐私保护的重要突破。 核心新功能 1. App Intents Agent框架 这是Apple Intelligence 2.0最重要的新功能。开发者可以通过App Intents框架让自己的App被AI Agent控制： ...

引言 传统的Agent架构是请求-响应式的：用户发请求，Agent处理后返回响应。这种模式简单直观，但在复杂的多Agent协作、实时响应和大规模并发场景中显得力不从心。 事件驱动架构（EDA）为Agent系统带来了新的设计范式。Agent不再被动等待请求，而是主动响应系统中发生的事件。这种模式更接近人类的工作方式——我们不是一直在等别人问问题，而是根据周围发生的事件做出反应。 一、为什么Agent需要事件驱动 1.1 解耦 请求-响应模式下，调用者必须知道被调用者的地址和能力。事件驱动模式下，事件发布者不需要知道谁会处理这个事件——它只管发布，订阅者自行处理。 1.2 异步 Agent的操作往往耗时较长（LLM推理、工具调用）。同步等待会阻塞整个系统。事件驱动天然支持异步处理，提高系统吞吐量。 1.3 可扩展 新功能可以通过添加新的事件订阅者实现，不需要修改现有Agent。例如，想要在Agent完成分析后自动发送通知，只需添加一个订阅"analysis_complete"事件的通知Agent。 1.4 实时响应 在需要实时响应的场景中（如监控告警、用户交互），事件驱动比轮询更高效、更及时。 二、事件驱动Agent架构 2.1 核心组件 ┌─────────────────────────────────────────┐ │ 事件总线 │ │ (Event Bus / Message Queue) │ └──────┬──────────┬──────────┬────────────┘ │ │ │ ┌────▼───┐ ┌───▼────┐ ┌───▼────┐ │ Agent A │ │ Agent B │ │ Agent C │ │Publisher│ │Subscriber│ │Sub.+Pub│ └────────┘ └────────┘ └────────┘ 事件总线：负责事件的传递。2026年的主流选择包括Kafka、NATS、Redis Streams和Pulsar。 事件发布者：产生事件的Agent。例如，数据分析Agent完成分析后发布"analysis_complete"事件。 事件订阅者：监听并处理事件的Agent。例如，通知Agent订阅"analysis_complete"事件，收到后发送通知。 混合角色：Agent可以同时是发布者和订阅者。 2.2 事件设计 一个良好的事件结构应该包含： { "event_id": "evt-uuid-001", "event_type": "task.completed", "source": "data-analyst-agent-01", "timestamp": "2026-07-01T10:00:00.123Z", "version": "1.2", "correlation_id": "task-uuid-001", "payload": { "task_id": "task-uuid-001", "result": {...}, "metrics": { "duration_ms": 15000, "tokens_used": 5000 } }, "metadata": { "environment": "production", "priority": "normal" } } 2.3 事件类型分类 领域事件：业务逻辑相关的事件。如"订单已创建"、“分析已完成”。 ...

Copilot的2026蜕变：从助手到Agent 2026年6月，Microsoft在Build 2026大会上发布了Copilot企业版的重大更新。这次更新的核心主题是"从助手到Agent"——Copilot不再只是一个帮你写邮件、做PPT的AI助手，而是一个能自主完成复杂工作流的智能体。 这次更新涵盖了Microsoft 365全家桶、Dynamics 365、Power Platform和Azure AI，共推出了超过40项新功能。本文聚焦其中最具变革性的10项。 核心新功能 1. Copilot Agent Studio 这是本次更新最重要的新功能。Agent Studio允许企业用户通过自然语言描述创建定制化的AI Agent： 用户描述： "帮我创建一个销售跟进Agent。它需要： 1. 每天检查CRM中的新线索 2. 对每个线索进行评分（基于历史成单数据） 3. 给高优先级线索自动发送个性化邮件 4. 在Teams中通知对应销售代表 5. 每周五生成跟进报告" Copilot Agent Studio → 自动创建、测试、部署Agent Agent Studio的工作流程： 理解：解析用户的自然语言描述，识别任务、触发条件、输出格式 设计：生成Agent的工作流图，标注每个步骤使用的工具和数据源 构建：自动编写代码（Power Automate流程 + Azure Functions） 测试：在沙箱环境中运行Agent，验证行为 部署：一键部署到Microsoft 365环境 创建的Agent可以跨Outlook、Teams、SharePoint、Dynamics 365等系统工作，无需编程。 2. 深度集成GPT-6和Claude 5 Copilot企业版不再局限于OpenAI模型。Microsoft在Azure AI Foundry中集成了多模型路由： GPT-6：用于复杂推理和代码生成 Claude 5：用于长文档分析和内容创作 Phi-4：用于轻量级实时任务 Llama 4：用于私有部署场景 系统会根据任务类型自动选择最合适的模型，用户也可以手动指定。这种多模型策略使得Copilot在不同场景下都能提供最佳性能。 3. 会议实时Agent Teams会议中的Copilot迎来了重大升级： 实时议程管理：根据讨论内容动态调整议程 行动项提取：自动识别会议中的决策和待办事项 实时翻译：支持40种语言的实时翻译和字幕 智能打断：当讨论偏离主题时温和提醒 会后总结：30秒内生成结构化会议纪要 最令人印象深刻的是"实时Agent"功能——在会议中，Copilot可以主动参与讨论。例如，当讨论到某个技术方案时，Copilot会自动检索相关文档并分享到聊天中。 ...

引言 在多智能体系统中，每个Agent都可能犯错。当多个Agent协作时，错误会级联放大。如何在系统层面保证质量？答案就是监督者架构（Supervisor Architecture）。 监督者不是简单的"监工"，而是一个集质量控制、冲突协调、资源管理于一体的系统层组件。2026年，随着多智能体系统规模扩大，监督者架构已经成为生产部署的必备组件。 一、监督者的角色定位 1.1 质量守门人 监督者对Agent的输出进行质量检查，只有通过标准的结果才能进入下一环节。这是最基础的监督角色。 1.2 冲突仲裁者 当多个Agent给出矛盾的结果时，监督者负责仲裁。例如，两个分析Agent对同一数据给出相反的结论，监督者需要判断哪个更可信。 1.3 资源调度者 监督者监控各Agent的资源使用情况，动态调整资源分配。当某个Agent过载时，可以将其部分任务转移给空闲Agent。 1.4 异常处理者 当Agent出现异常（超时、错误、异常行为）时，监督者负责处理。包括重试、降级、切换Agent或升级处理。 二、监督模式 2.1 事前监督 在Agent执行前审查计划： Worker Agent: 提交执行计划 Supervisor: 审查计划 → 计划合理: 批准执行 → 计划有问题: 要求修改 → 计划危险: 拒绝并报告 优势：防止错误发生，成本最低。 劣势：可能过度限制Agent的自主性，增加延迟。 2.2 事中监督 在Agent执行过程中实时监控： Worker Agent: 正在执行步骤3/10 Supervisor: 监控执行状态 → 正常: 继续 → 偏离: 发出警告 → 严重偏离: 中断执行 优势：及时发现问题，避免浪费。 劣势：需要实时监控，资源开销大。 2.3 事后监督 在Agent完成后审查结果： Worker Agent: 返回结果 Supervisor: 审查结果 → 质量达标: 接受 → 质量不达标: 要求重做 → 严重问题: 人工审核 优势：不影响执行过程，开销小。 劣势：发现问题晚，可能需要大量返工。 ...

AMD的反击：MI400正式官宣 2026年6月18日，AMD在拉斯维加斯举办的"AI Power"大会上正式宣布了Instinct MI400系列AI加速器。这是AMD CDNA 4架构的首款产品，也是AMD有史以来性能最强的AI芯片。 AMD CEO Lisa Su在发布会上直言不讳地表示：“MI400的目标是在每一个关键指标上匹配或超越NVIDIA Blackwell Ultra。“这一定位标志着AMD不再满足于"高性价比替代品"的角色，而是要正面对抗NVIDIA的旗舰产品。 MI400规格详解 核心架构 MI400采用AMD CDNA 4架构，基于台积电3nm工艺（N3P），使用Chiplet设计： 规格 MI400 MI300X B300 (对比) 架构 CDNA 4 CDNA 3 Blackwell 制程 3nm (N3P) 5nm+6nm 3nm (N3P) Chiplet 12个XCD+8个IOD 8个XCD+4个IOD 双芯片 计算单元 384 CU 304 CU - 流处理器 98,304 19,528 - 晶体管 ~185B 153B 208B 计算性能 精度 MI400 MI300X B300 FP64 120 TFLOPS 163 TFLOPS - FP64矩阵 240 TFLOPS 326 TFLOPS - FP32 240 TFLOPS 163 TFLOPS - FP16/BF16 9,600 TFLOPS 2,615 TFLOPS 3,750 TFLOPS FP8 19,200 TFLOPS 5,228 TFLOPS 7,500 TFLOPS INT8 38,400 TOPS 10,457 TOPS - FP4 N/A N/A 15,000 TFLOPS MI400的FP8性能达到19.2 PFLOPS，是B300的2.56倍。这个数据让业界震惊——AMD在FP8精度上首次大幅超越NVIDIA的旗舰产品。 ...

引言 在人类组织中，委派是管理的核心技能——将任务分解并分配给合适的人，是完成复杂项目的基础。同样，在多智能体系统中，委派模式决定了系统的效率和可扩展性。 一个好的委派系统就像一个高效的组织：每个层级各司其职，信息自上而下传达指令，自下而上汇报结果，整体协同完成复杂目标。 一、委派的基本模式 1.1 直接委派 最简单的委派模式：Agent A直接将任务交给Agent B执行。 Manager Agent: "请查询2025年Q4的销售数据并生成图表" → Data Analyst Agent: 执行查询 → 生成图表 → 返回结果 Manager Agent: 收到结果，继续下一步 适用场景：任务明确、单一执行者、无需协调。 1.2 广播委派 一个Agent将任务同时委派给多个Agent，各自独立处理： Manager Agent: "分别调研三个竞品的市场策略" → Agent 1: 调研竞品A → Agent 2: 调研竞品B → Agent 3: 调研竞品C Manager Agent: 汇总三个Agent的结果 适用场景：任务可以独立并行、无需Agent间协调。 1.3 链式委派 任务沿链传递，每个Agent处理一部分后传给下一个： Manager → Collector(收集数据) → Analyzer(分析数据) → Reporter(生成报告) → Manager 适用场景：流程固定的流水线任务。 1.4 竞争委派 同一任务委派给多个Agent，选择最优结果： Manager: "设计系统架构" → Agent 1: 方案A → Agent 2: 方案B → Agent 3: 方案C Manager: 评估三个方案，选择最优或融合 适用场景：创意性任务、需要多视角的任务。 ...

Blackwell Ultra：NVIDIA的2026年旗舰 2026年Q2，NVIDIA Blackwell Ultra GPU（B300系列）正式开始规模出货。作为Blackwell架构的第二代产品，B300在性能、能效和功能上都带来了显著提升。第一批拿到货的客户包括Meta、Microsoft、Google和Oracle，他们已经在生产环境中部署了B300集群。 本文基于NVIDIA官方数据和早期客户的实测结果，全面解析Blackwell Ultra的性能表现。 规格概览 B300 vs B200 vs H200 规格 B300 (Blackwell Ultra) B200 (Blackwell) H200 (Hopper) 制程 TSMC 3NP TSMC 4NP TSMC 4N 晶体管 208B 208B 80B 双芯片设计 是 是 否 FP4张量性能 15 PFLOPS 9 PFLOPS 4 PFLOPS FP8张量性能 7.5 PFLOPS 4.5 PFLOPS 2 PFLOPS FP16/BF16 3.75 PFLOPS 2.25 PFLOPS 1 PFLOPS 显存 192GB HBM3e 192GB HBM3e 141GB HBM3e 显存带宽 8.0 TB/s 8.0 TB/s 4.8 TB/s 功耗(TDP) 1200W 1000W 700W 互联 NVLink 5 (1.8TB/s) NVLink 5 (1.8TB/s) NVLink 4 (900GB/s) B300的FP4性能达到15 PFLOPS，是H200的3.75倍。但功耗也从700W上升到1200W，这对数据中心的供电和散热提出了更高要求。 ...

2000亿美元：AI投资进入新纪元 根据PitchBook和CB Insights的联合数据，2026年上半年全球AI领域融资总额达到2087亿美元，较2025年同期增长47%。这个数字已经接近2024年全年的AI融资总额。 AI投资在全部风险投资中的占比从2025年的28%上升至41%。换句话说，现在每投出2.5元风险投资，就有1元流向AI。 融资全景 按阶段分布 融资阶段 交易数 总金额 平均金额 种子轮 1,247 $18B $14M A轮 683 $42B $62M B轮 412 $51B $124M C轮+ 287 $68B $237M 巨额轮（>$1B） 12 $29B $2.4B 值得注意的是"巨额轮"——单笔超过10亿美元的融资交易达到了12笔，总额290亿美元。这些资金几乎全部流向了基础模型公司。 按领域分布 1. 基础模型（$62B，30%） 仍然是最大的投资领域。OpenAI、Anthropic、xAI、DeepSeek等公司在这一轮中获得了巨额融资。 2. AI芯片与硬件（$38B，18%） AI芯片创业公司和数据中心硬件公司持续获得大额投资。 3. AI Agent与自动化（$35B，17%） Agent平台、RPA增强、工作流自动化成为2026年最热的投资方向。 4. 垂直行业AI（$31B，15%） 医疗AI、法律AI、金融AI等垂直应用持续增长。 5. AI基础设施（$24B，11%） 向量数据库、MLOps平台、训练框架等基础设施。 6. AI安全与治理（$9B，4%） AI对齐、可解释性、内容安全等方向。 7. 其他（$9B，5%） 按地区分布 地区 融资总额 占比 同比增长 美国 $98B 47% +38% 中国 $52B 25% +62% 欧洲 $28B 13% +51% 其他亚太 $21B 10% +55% 其他 $10B 5% +42% 中国AI融资增速最快（+62%），主要得益于DeepSeek V4的成功带动的国内AI投资热潮。美国仍然占据近半份额，但占比从2025年的52%下降到47%。 ...

引言 工作流引擎是Agent系统的"操作系统"——它负责任务的分解、调度、执行和监控。一个好的工作流引擎能让Agent像训练有素的团队一样高效协作；而一个糟糕的工作流引擎则会让Agent陷入混乱。 2026年，Agent工作流引擎已经从简单的DAG执行器演进为支持动态流程、条件分支、并行调度和实时监控的复杂系统。本文将深入剖析其设计原理。 一、工作流模型 1.1 DAG模型 有向无环图（DAG）是最基础的工作流模型。每个节点是一个任务，边表示依赖关系。 [数据收集] / \ [清洗数据] [验证数据] \ / [数据分析] | [生成报告] DAG模型的优点是简单、可分析、无循环依赖。但缺点也很明显：不支持循环和条件分支，无法表达复杂的业务逻辑。 1.2 BPMN模型 业务流程模型和标记法（BPMN）支持更丰富的流程元素： 网关：排他网关（XOR）、并行网关（AND）、包容网关（OR） 事件：开始事件、结束事件、中间事件、边界事件 子流程：将一组任务封装为子流程 错误处理：异常处理和补偿机制 BPMN模型适合企业级复杂流程，但实现复杂度较高。 1.3 动态流程模型 2026年的趋势是动态流程——工作流不是预先定义的，而是在运行时由Agent动态生成和修改。 Agent接收任务 → 生成初步计划 → 执行第一步 → 根据结果调整计划 → 执行下一步 → ... 这种模型最灵活，但也最难管理。需要在灵活性和可控性之间找到平衡。 二、调度引擎设计 2.1 调度器架构 ┌──────────────────────────────────────┐ │ 任务调度器 │ ├──────────┬──────────┬─────────────────┤ │ 就绪队列 │ 执行池 │ 完成队列 │ │ (pending)│(running) │ (completed) │ ├──────────┴──────────┴─────────────────┤ │ 依赖解析器 │ ├───────────────────────────────────────┤ │ 状态存储 │ └───────────────────────────────────────┘ 调度器的核心职责： ...