为什么企业需要上下文图：Merge 联合创始人 Gil Feig 的构建思路

📌 One-Sentence Summary

Merge 联合创始人 Gil Feig 提议用企业上下文图，将智能体请求分流到技能、记忆、实时 API、同步数据和派生摘要，并保留数据时效、权限与来源记录。

📝 Summary

Gil Feig 认为，只连接几个 MCP 工具不足以回答横跨整个组织的问题。查询某一位客户为何不满，也许只需实时读取工单；若要找出过去一年哪些客户不满，就需要同步大量记录，建立可查询的副本。他提出的上下文层包含四类内容：提示词、技能与记忆；实时 API；同步或缓存的数据；以及从已有资料生成的摘要。路由器选择数据源，摘要器压缩结果，公司专属技能则解释「客户满意」等词在本组织中的含义。检索流程先检查缓存是否满足时效要求，过期时改用实时 API，并可保存有用的派生摘要以供复用。Feig 强调，每条信息都应保留来源、获取时间、访问身份、权限、变换过程和失效规则，让决策可追溯。这是一套有具体客服场景和实时访问与同步取舍的企业架构，但仍偏概念说明，缺少实现细节或量化效果；结尾的产品介绍也体现了 Merge 的厂商立场。

💡 Main Points

实时工具和同步数据适合不同的访问模式。

针对单个客户的查询可用 API；跨数千张工单的语义或历史问题则需要建立本地索引副本。

公司技能提供原始记录之外的业务含义。

「不满的客户」可能取决于问卷、工单或内部规则；技能引导智能体到正确位置寻找证据。

数据时效决定使用缓存还是实时检索。

上下文层可在 SLA 允许时使用同步数据，过期后调用实时 API，并为重复问题生成派生摘要。

每项检索或派生的事实都要保留来源。

数据源、时间、访问身份、权限、变换和失效条件，使记录变化或决策出错后的追查成为可能。

💬 Key Quotes

MCP 还不能完全解决这些问题，因为其他平台 API 的访问模式不支持纯实时查询。

不要丢掉数据来源，一定要保存下来。

数据并非越多越好。

最后，每个答案都必须可追溯。

📊 Article Meta

AI Screening： 90

Featured： Yes

Source： AI Engineer

Author： AI Engineer

Category： 人工智能

Language： 英文

Read Time： 13 min

Word Count： 3106

Tags：

AI 与智能应用 , AI Agent , Agent记忆 , MCP协议 , 系统设计

Play Full Video