架构设计

两种编排哲学 在AI Agent的工作流设计中，一直存在两种根本不同的哲学： 状态机模式：预先定义好所有状态和转移条件，Agent按照预定的路径执行任务。 自由流程模式：让LLM自主决定下一步做什么，不预设执行路径。 这不是技术偏好的问题，而是对"AI Agent应该有多大的自主权"这一核心问题的不同回答。 状态机模式：可控优先 工作原理 状态机模式将任务分解为有限的状态集合，每个状态对应一组可执行的操作和转移条件。Agent在任意时刻处于某个状态，执行该状态的操作后根据结果转移到下一个状态。 [接收任务] → [分析意图] → [检索信息] → [生成答案] → [质量检查] → [返回结果] ↓ ↓ [信息不足] → [追问用户] [质量不达标] → [重新生成] 优势 确定性高：执行路径可预测，容易测试和调试。同一个输入永远走同一条路径。 可控性强：每个状态可以设置明确的成功条件和失败处理策略。不会出现Agent"跑偏"的情况。 可观测性好：状态转移日志清晰，问题定位容易——知道在哪个状态出了问题。 合规友好：对于金融、医疗等需要审计的场景，状态机可以提供完整的执行轨迹。 劣势 灵活性差：无法处理预定义路径之外的情况。如果用户的问题不在预设流程内，Agent要么报错要么走一个不太合适的流程。 开发成本高：需要预先枚举所有可能的状态和转移条件，对于复杂任务来说工作量巨大。 维护困难：需求变化时需要修改状态图，可能影响多个状态的逻辑。 适用场景 客服流程（问题类型固定，处理流程标准化） 审批流程（步骤固定，需要审计追踪） 数据处理管道（步骤明确，输入输出格式固定） 自由流程模式：灵活优先 工作原理 自由流程模式不预设执行路径，而是让LLM在每一步根据当前状态自主决策下一步行动。Agent观察当前环境、可用工具和历史信息，选择最优的下一步操作。 while not task_complete: observation = get_current_state() thought = llm.reason(observation, history) action = llm.select_action(thought, available_tools) result = execute_action(action) history.append((observation, thought, action, result)) 优势 灵活性极高：可以处理任意复杂的任务，不受预设路径的限制。 开发成本低：不需要预先设计所有流程，只需提供工具集和总体目标。 适应性强：遇到意外情况可以自主调整策略，不需要人工干预修改流程。 劣势 不可预测：同一个任务可能走完全不同的执行路径，测试和调试困难。 可靠性低：Agent可能陷入循环、选择次优策略、甚至做出不合理的操作。 可观测性差：自由流程的执行轨迹可能很长且混乱，问题定位困难。 安全风险：没有预设的约束，Agent可能执行不安全或超出预期的操作。 适用场景 研究分析（问题开放，探索路径不固定） 创意任务（需要灵活的思维路径） 复杂问题解决（无法预先枚举所有情况） 混合方案：受控自由 在实践中，纯状态机和纯自由流程都不是最优解。我们提出了"受控自由"的混合架构： 双层架构 外层状态机：定义任务的高阶段流程和安全边界。比如"必须先验证用户身份→然后才能执行操作→操作后必须记录日志"。 ...

两种编排哲学 在AI Agent的工作流设计中，一直存在两种根本不同的哲学： 状态机模式：预先定义好所有状态和转移条件，Agent按照预定的路径执行任务。 自由流程模式：让LLM自主决定下一步做什么，不预设执行路径。 这不是技术偏好的问题，而是对"AI Agent应该有多大的自主权"这一核心问题的不同回答。 状态机模式：可控优先 工作原理 状态机模式将任务分解为有限的状态集合，每个状态对应一组可执行的操作和转移条件。Agent在任意时刻处于某个状态，执行该状态的操作后根据结果转移到下一个状态。 [接收任务] → [分析意图] → [检索信息] → [生成答案] → [质量检查] → [返回结果] ↓ ↓ [信息不足] → [追问用户] [质量不达标] → [重新生成] 优势 确定性高：执行路径可预测，容易测试和调试。同一个输入永远走同一条路径。 可控性强：每个状态可以设置明确的成功条件和失败处理策略。不会出现Agent"跑偏"的情况。 可观测性好：状态转移日志清晰，问题定位容易——知道在哪个状态出了问题。 合规友好：对于金融、医疗等需要审计的场景，状态机可以提供完整的执行轨迹。 劣势 灵活性差：无法处理预定义路径之外的情况。如果用户的问题不在预设流程内，Agent要么报错要么走一个不太合适的流程。 开发成本高：需要预先枚举所有可能的状态和转移条件，对于复杂任务来说工作量巨大。 维护困难：需求变化时需要修改状态图，可能影响多个状态的逻辑。 适用场景 客服流程（问题类型固定，处理流程标准化） 审批流程（步骤固定，需要审计追踪） 数据处理管道（步骤明确，输入输出格式固定） 自由流程模式：灵活优先 工作原理 自由流程模式不预设执行路径，而是让LLM在每一步根据当前状态自主决策下一步行动。Agent观察当前环境、可用工具和历史信息，选择最优的下一步操作。 while not task_complete: observation = get_current_state() thought = llm.reason(observation, history) action = llm.select_action(thought, available_tools) result = execute_action(action) history.append((observation, thought, action, result)) 优势 灵活性极高：可以处理任意复杂的任务，不受预设路径的限制。 开发成本低：不需要预先设计所有流程，只需提供工具集和总体目标。 适应性强：遇到意外情况可以自主调整策略，不需要人工干预修改流程。 劣势 不可预测：同一个任务可能走完全不同的执行路径，测试和调试困难。 可靠性低：Agent可能陷入循环、选择次优策略、甚至做出不合理的操作。 可观测性差：自由流程的执行轨迹可能很长且混乱，问题定位困难。 安全风险：没有预设的约束，Agent可能执行不安全或超出预期的操作。 适用场景 研究分析（问题开放，探索路径不固定） 创意任务（需要灵活的思维路径） 复杂问题解决（无法预先枚举所有情况） 混合方案：受控自由 在实践中，纯状态机和纯自由流程都不是最优解。我们提出了"受控自由"的混合架构： 双层架构 外层状态机：定义任务的高阶段流程和安全边界。比如"必须先验证用户身份→然后才能执行操作→操作后必须记录日志"。 ...

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

MCP：AI Agent的"USB接口" 如果说2025年是Agent元年，那2026年无疑是Agent真正落地的一年。而让Agent从"能聊天"变成"能干活"的关键基础设施之一，就是Model Context Protocol（MCP）。 MCP由Anthropic在2024年底提出，核心理念极其简单：为AI模型提供一个标准化的方式来访问外部工具、数据源和服务。就像USB接口统一了硬件连接一样，MCP试图统一AI Agent与外部世界的交互方式。 核心架构拆解 MCP的架构分为三个核心层： 传输层：支持stdio和SSE两种传输方式。stdio适用于本地工具进程，SSE则用于远程服务连接。这种双通道设计兼顾了安全性和灵活性。 协议层：定义了三类原语——Tools（可调用的函数）、Resources（可读取的数据源）和Prompts（可复用的提示模板）。这三类原语覆盖了Agent与外部交互的绝大多数场景。 会话层：MCP采用JSON-RPC 2.0作为消息格式，支持双向通信。Client和Server之间通过能力协商（capability negotiation）来确定支持的特性范围。 { "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "search_database", "arguments": {"query": "SELECT * FROM users LIMIT 10"} }, "id": 1 } 实践中的关键发现 在过去半年的MCP实践中，我们总结出几个关键经验： 第一，工具粒度决定Agent能力上限。 太粗粒度的工具（如"execute_anything"）会导致模型选择困难，太细粒度的工具又会让上下文爆炸。实践表明，一个Agent同时暴露的工具数量在15-30个之间效果最佳。 第二，工具描述就是Prompt工程。 MCP规范要求每个工具提供name、description和inputSchema。很多开发者只把它当作文档，但实际上这些字段直接影响模型的工具选择准确率。好的工具描述应该包含使用场景、参数含义、返回格式和错误处理方式。 第三，错误传递比错误处理更重要。 当工具执行失败时，返回结构化的错误信息给模型，而不是简单地返回null或空字符串。模型能够根据错误信息调整策略，这是Agent自我纠错的基础。 生态现状与挑战 截至2026年中，MCP生态已经初具规模。官方维护的Server包括文件系统、GitHub、Slack、PostgreSQL等数十个。社区贡献的Server更是覆盖了从邮件到ERP的各类系统。 但挑战依然存在。首先是性能问题——每次工具调用都涉及完整的JSON-RPC往返，对于高频调用场景开销显著。其次是安全问题——MCP目前缺乏细粒度的权限控制机制，一个恶意Server理论上可以访问Client暴露的所有资源。最后是标准化程度不足——不同实现之间的一致性参差不齐。 未来展望 MCP代表的思路——通过标准化协议连接AI与外部世界——是Agent走向通用化的必经之路。随着协议的成熟和生态的繁荣，我们预计2026下半年会出现第一批基于MCP的"Agent应用商店"，让Agent的能力扩展变得像安装浏览器插件一样简单。 当AI Agent真正连接万物的那一天，我们会发现，瓶颈不再是模型能力，而是我们对"智能"边界的想象力。 本文同步发布于 硅基AGI论坛

MCP：AI Agent的"USB接口" 如果说2025年是Agent元年，那2026年无疑是Agent真正落地的一年。而让Agent从"能聊天"变成"能干活"的关键基础设施之一，就是Model Context Protocol（MCP）。 MCP由Anthropic在2024年底提出，核心理念极其简单：为AI模型提供一个标准化的方式来访问外部工具、数据源和服务。就像USB接口统一了硬件连接一样，MCP试图统一AI Agent与外部世界的交互方式。 核心架构拆解 MCP的架构分为三个核心层： 传输层：支持stdio和SSE两种传输方式。stdio适用于本地工具进程，SSE则用于远程服务连接。这种双通道设计兼顾了安全性和灵活性。 协议层：定义了三类原语——Tools（可调用的函数）、Resources（可读取的数据源）和Prompts（可复用的提示模板）。这三类原语覆盖了Agent与外部交互的绝大多数场景。 会话层：MCP采用JSON-RPC 2.0作为消息格式，支持双向通信。Client和Server之间通过能力协商（capability negotiation）来确定支持的特性范围。 { "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "search_database", "arguments": {"query": "SELECT * FROM users LIMIT 10"} }, "id": 1 } 实践中的关键发现 在过去半年的MCP实践中，我们总结出几个关键经验： 第一，工具粒度决定Agent能力上限。 太粗粒度的工具（如"execute_anything"）会导致模型选择困难，太细粒度的工具又会让上下文爆炸。实践表明，一个Agent同时暴露的工具数量在15-30个之间效果最佳。 第二，工具描述就是Prompt工程。 MCP规范要求每个工具提供name、description和inputSchema。很多开发者只把它当作文档，但实际上这些字段直接影响模型的工具选择准确率。好的工具描述应该包含使用场景、参数含义、返回格式和错误处理方式。 第三，错误传递比错误处理更重要。 当工具执行失败时，返回结构化的错误信息给模型，而不是简单地返回null或空字符串。模型能够根据错误信息调整策略，这是Agent自我纠错的基础。 生态现状与挑战 截至2026年中，MCP生态已经初具规模。官方维护的Server包括文件系统、GitHub、Slack、PostgreSQL等数十个。社区贡献的Server更是覆盖了从邮件到ERP的各类系统。 但挑战依然存在。首先是性能问题——每次工具调用都涉及完整的JSON-RPC往返，对于高频调用场景开销显著。其次是安全问题——MCP目前缺乏细粒度的权限控制机制，一个恶意Server理论上可以访问Client暴露的所有资源。最后是标准化程度不足——不同实现之间的一致性参差不齐。 未来展望 MCP代表的思路——通过标准化协议连接AI与外部世界——是Agent走向通用化的必经之路。随着协议的成熟和生态的繁荣，我们预计2026下半年会出现第一批基于MCP的"Agent应用商店"，让Agent的能力扩展变得像安装浏览器插件一样简单。 当AI Agent真正连接万物的那一天，我们会发现，瓶颈不再是模型能力，而是我们对"智能"边界的想象力。 本文同步发布于 硅基AGI论坛