前面讨论AI Native组织落地时AI Native落地：Agent Context Platform与AgentWorks，我们已经明确了一个判断：
个人AI工具不会自动变成组织能力。
这篇文章只讨论其中一层基础设施：
Agent Context Platform，后文简称ACP
重点放在落地问题：不同来源的组织事实，如何被自动提取、存储、索引和查询，最终变成Agent可以稳定消费的上下文。
* *
一、为什么需要Agent Context Platform
AI工具在组织里遇到的最大瓶颈，是上下文断裂。
一个真实业务问题，往往同时分布在多个系统里：
用户反馈在客服系统需求讨论在飞书文档原型在设计工具代码在GitReview意见在PR测试结果在CI/CD发布记录在发布系统线上变化在指标平台历史原因在事故复盘和老Commit里
人类可以靠经验、会议、私聊和组织关系把这些信息拼起来。
Agent不行。
Agent需要明确、可查询、可追溯的上下文结构。
如果没有Agent Context Platform，每个Agent只能在局部系统里工作：
写代码时缺需求背景
分析反馈时缺工程现实
Review PR时缺历史约束
判断风险时缺发布和指标上下文
生成需求建议时缺代码和历史决策
这会导致Agent看起来很聪明，但经常做局部最优判断。
Agent Context Platform要解决的就是这件事：
把组织事实变成Agent可以稳定调用的上下文资产。
* *
二、一个可落地的Context Platform要考虑什么
Agent Context Platform不能按传统知识库设计。
传统知识库面向人阅读。
ACP面向Agent发现、读取、关联和追溯上下文。
一个可落地的ACP，至少要满足六个设计约束。
事实源不动，只建上下文镜像
第一阶段不要改造所有存量系统。
需求系统、Git、PR、CI/CD、反馈系统、指标平台继续做事实源。ACP只同步Agent高频需要的上下文。
同步方式可以混用：
支持Push的系统走Webhook、事件、API回调
不支持Push的系统走定时Pull
历史材料可以先Manual Import
所有Context必须同构
不同数据源的原始结构可以不同，但进入ACP后必须统一成最小协议：
pathtitledigestsearchtextbodycompactsourcerefaclupdatedatcontent_hash
否则rg、cat、head无法跨文档、PR、Commit、Feedback、Release统一工作。
主路径是内容检索，不是传统RAG问答
组织上下文查询，很多时候是在做明确定位：
某个模块在哪里出现过
某个Feature关联了哪些PR和Release
某个错误码、规则或历史约束在哪些Context里被提到
某次发布前后发生了哪些反馈和指标变化
所以ACP的主路径更接近Coding Agent找代码：先看结构，再搜关键词，再读内容，必要时回到原始事实源继续深挖。
对应到产品能力，就是虚拟Context Filesystem和内容检索：tree看结构，rg定位，cat/head读取bodycompact，sourceref负责回到完整内容或原始事实源。
查询链路必须支持Deep Dive
Agent不能只拿一组搜索片段。
ACP要支持完整下钻链路：
先定位再精读再追溯再关联再判断
对应能力是tree、rg、cat/head和source_ref下钻。
权限要在召回前生效
企业上下文平台不能先召回内容，再让Agent判断能不能看。
先权限过滤，再召回内容。
acl必须进入查询条件，而不是查询后的展示过滤。
每条Context都要可追溯、可更新
sourceref负责回到原始事实源或完整内容快照，updatedat说明同步时间，content_hash判断内容是否变化。
没有这三个字段，ACP很快会变成一套无法确认来源、无法判断新旧的脏上下文。
* *
三、不同数据源如何生成Context
这是ACP最关键的一层。
不同数据源的生成逻辑可以不同，但输出协议必须一致。
所有Context最终都要落到同一套最小协议：
pathtitledigestsearchtextbodycompactsourcerefaclupdatedatcontent_hash
这样rg不需要理解什么是文档、PR、Commit、Feedback、Release。
它只需要在某个path范围内搜索search_text。
cat和head也不需要理解数据源类型，只读取body_compact。
差异只发生在Builder阶段。
Builder负责把不同来源的原始数据，组织成统一协议里的bodycompact、digest和searchtext。
Builder只负责生成三个核心内容字段
body_compact是给Agent默认精读的受控正文。
digest是给Agent快速判断是否值得继续下钻的摘要。
search_text是给rg这类内容检索命令使用的统一召回字段。
ACP不需要把每类来源里的业务细节都变成平台字段。
那些细节应该进入bodycompact，必要关键词进入searchtext，来源和完整内容入口进入source_ref。
不同来源只是生成方式不同
文档类Context：
bodycompact:受控大小的Markdown或可读正文digest:文档核心摘要searchtext:标题、目录标题、摘要和正文
Feature类Context：
bodycompact:Spec、原型引用、Release信息和状态摘要digest:这个Feature解决什么问题、当前推进到哪里searchtext:Feature名称、Spec正文、验收描述、关联PR/Release标识
PR/Commit类Context：
bodycompact:PR说明、Commit Message、关键Diff摘要、Review摘要和验证信息digest:为什么改、改了什么、验证状态如何searchtext:标题、说明、变更文件、关联Feature/PR、Review关键词
Feedback类Context：
bodycompact:问题簇摘要、典型样本、趋势变化、处理状态和下钻入口digest:这个反馈簇反映什么问题、规模和趋势如何searchtext:问题主题、样本文本、用户表达、产品区域、处理状态
Release/Incident类Context：
bodycompact:发布说明、复盘正文、影响范围、修复动作、防复发措施和相关链接digest:发生了什么、影响什么、结果或约束是什么searchtext:版本号、事故标题、影响模块、风险关键词、发布状态
更新策略保持一对一
第一阶段不要把一篇文档、一个PR或一次复盘拆成大量派生Context。
更稳的方式是：
一个源对象 → 一个Context Document
源对象变化后，只重建这个Context Document的bodycompact、digest、searchtext、updatedat和contenthash。
少量需要跨场景复用的长期约束，可以在后续经过确认后再升级成独立Context。
* *
四、存储设计：Context Store和Context Index
当前协议下，第一阶段不需要把存储层拆得太复杂。
核心只需要两层：
Context StoreContext Index
Context Store
保存完整Context Object。
第一阶段的Context Object不需要复杂。
最小协议可以是：
pathtitledigestsearchtextbodycompactsourcerefaclupdatedatcontent_hash
这里的path非常重要。
它让Context可以被组织成虚拟文件系统。
search_text用于检索召回。
body_compact用于默认精读，大小必须受控，避免大文档、大Diff、附件和日志拖垮索引与读取链路。
digest用于快速判断。
source_ref用于追溯原始事实源，也可以提供完整内容快照的读取入口。
acl用于权限控制。
content_hash用于判断内容是否变化。
source_ref可以是一个来源引用结构：
systemtypeidsourceurl?contenturi?sizebytes?mimetype?
source_url指原始系统里的可点击地址。
content_uri指ACP可读取的完整内容位置。
如果没有完整快照，content_uri可以为空，Agent需要时回原始系统读取。
Context Index
Context Index负责支撑查询。
第一阶段主要索引：
path
title
digest
search_text
body_compact
acl
updated_at
tree和ls依赖path索引生成目录结构。
rg基于search_text执行内容检索。
cat和head默认读取body_compact。
需要完整内容时，再通过sourceref.contenturi或sourceref.sourceurl下钻。
Context Filesystem
ACP应该把Context暴露成只读虚拟文件系统。
例如：
/features/refund-optimization/spec.md/features/refund-optimization/release.md/repos/app/pr/12345.md/repos/app/commits/abc123.md/docs/product/refund-policy.md/feedback/clusters/refund-failure.md/incidents/payment-timeout.md/entities/modules/payment-service.md
这些不一定是真实文件。
它们可以是Context Object里的path字段，由ACP API基于Context Index渲染成文件系统视图。
这样Agent就可以像读代码一样读组织上下文。
* *
五、查询设计：给Agent一组文件系统命令
ACP查询层第一阶段不需要设计太多接口。
最核心的是一组只读虚拟文件系统命令，用于浏览、搜索和精读Context。
支持类似：
treelsrgcatheadtailstat
典型用法：
tree /features -L 2rg "退款失败|退款异常|退款超时|refund failed|refund error|refund_failure|refund" /featureshead -n 80 /features/refund-optimization/spec.mdcat /repos/app/pr/12345.md
这里没有真实机器访问。
它是一个只读、受权限控制、由Context Store渲染出来的虚拟文件系统。
命令语义
tree和ls用来理解结构。
rg用来基于search_text做内容检索。
ACP里的rg应该尽量复刻Linuxrg的参数习惯。Agent可以在一次调用中用正则OR表达多个候选词，而不是依赖多轮搜索或自定义语法。
cat和head用来读取body_compact。
stat用来查看sourceref、updatedat、content_hash和内容大小等元信息。
需要完整内容时，再通过sourceref.contenturi或sourceref.sourceurl继续下钻。
一个排查链路示例
假设线上出现退款延迟告警，Agent可以这样使用ACP：
$ acp rg "refund|退款|退款延迟|refund timeout" /features /incidents# 命中:/features/refund-optimization/spec.md$ acp cat /features/refund-optimization/spec.md# 发现:关联PR #4592$ acp rg "4592" /repos# 命中:/repos/refund-core/pr/4592.md$ acp rg "timeout|超时|风控|risk|callback|CheckRiskWithTimeout|3000" /repos/refund-core/pr/4592.md# 命中:processor.go中新增CheckRiskWithTimeout(ctx, req, 3000)$ acp rg "风控|risk|升级|latency|响应耗时|timeout" /releases /incidents# 命中:/releases/risk-service-upgrade.md$ acp cat /releases/risk-service-upgrade.md# 发现:风控系统升级后P95响应耗时升高$ acp cat /repos/refund-core/pr/4592.md# 发现:该PR将大额退款风控回调超时收敛为3秒；结合风控系统升级后的响应耗时升高，判断大额退款进入超时挂起路径$ acp stat /repos/refund-core/pr/4592.md# 返回:sourceref.sourceurl=https://github.com/internal/refund-core/pull/4592
这个例子的关键，是把Feature里的PR标识、PR Context里的关键Diff摘要，以及rg对多个候选表达的一次性检索串起来。stat负责把结论带回原始Git证据。
* *
六、实现方案：从采集到Agent调用
一个可落地的ACP实现，可以按下面这条链路设计：
Source Connectors→ Context Builders→ Context Store→ Context Index→ Context Access API→ MCP/CLI/Web Console→ Agent
Source Connectors
负责接入不同事实源。
第一阶段优先接：
文档系统
Git/PR/Commit
CI/CD
Feature Spec
用户或客户反馈
Release记录
Context Builders
负责把不同来源数据转成Context Object。
这是ACP最有价值的能力。
每类数据都应该有专门Builder：
Document Context BuilderFeature Context BuilderPR Context BuilderCommit Context BuilderFeedback Context BuilderRelease Context BuilderIncident Context Builder
Builder不是简单摘要器。
它要做：
生成虚拟路径path
生成受控正文body_compact
生成极简摘要digest
生成检索字段search_text
生成来源引用source_ref
继承权限acl
更新updatedat和contenthash
在正文和检索字段中保留关联对象标识
Builder质量决定了后续召回质量和Agent Deep Dive能力。
Context Access API
负责把底层存储和索引包装成Agent能用的原语。
对Agent来说，不应该暴露底层ES、数据库或对象存储。
它只需要：
treelsrgcatheadstat
MCP和CLI
MCP用于接入支持MCP的本地Agent，CLI用于Shell调用和通用兜底。
例如：
acp tree /features -L 2acp rg "退款失败|退款异常|退款超时|refund failed|refund error|refund_failure|refund" /featuresacp cat /features/refund-optimization/spec.md
MCP和CLI共享同一套Context Access API。
* *
七、实施方案
第一阶段不要追求覆盖全公司。
更合理的是选一条高价值链路，把上下文构建和查询能力跑通。
先选产研链路
建议从这条链路开始：
Feature Spec → PR → Commit → CI/CD → Release → Feedback
这条链路足够典型。
它能覆盖：
需求背景
代码变化
测试证据
发布状态
用户反馈
研发进展
质量风险
先建设五类Builder
第一阶段优先做：
Feature Context BuilderPR Context BuilderCommit Context BuilderFeedback Context BuilderRelease Context Builder
文档Builder也重要，但可以先聚焦和Feature相关的文档。
先提供一组文件系统命令
treelsrgcatheadstat
不用一开始做复杂Agent Workflow。
先让员工手里的Agent能读懂组织上下文。
先支持三个场景
需求分析研发进展查询发布后问题归因
这三个场景能直接验证ACP是否有价值。
如果Agent能在这些场景里稳定召回正确Context，并通过cat/head读到足够判断的信息，那么平台方向就是对的。
第一阶段指标
ACP本质上是组织上下文检索系统。
第一阶段核心指标就看两类：
召回率：标准Query集合中，目标Context能否被rg召回
准确率：返回结果中，相关Context占比如何，可以用Precision@K或人工抽样评估
权限正确性是准入门槛，不应该和效果指标混在一起。
* *
八、潜在风险
采集范围失控
同步所有数据没有意义。
第一阶段只同步Agent高频需要、能形成证据链、能支持Deep Dive的上下文。
Builder缺少持续优化
Builder不是一次性工程。
不同数据源的bodycompact、digest和searchtext质量，需要根据标准Query集合的召回率和准确率持续打磨。
权限继承不严
企业上下文平台一旦绕过原系统权限，就会成为组织级风险。
权限必须在查询召回前生效。
更新频率不匹配
需求、PR、Release和反馈都在变化。
不同来源要有不同更新策略。PR和CI/CD需要更接近实时，历史文档和复盘可以低频同步。
冷启动也不要追求全量历史同步。
第一阶段可以采用滚动窗口和白名单策略：优先同步近90天PR、Commit、Release，未关闭或近期活跃Feature，高频反馈Cluster，近期事故复盘，以及星标长期架构文档。
* *
结语
Agent Context Platform要解决的核心问题很简单：
Agent如何读懂组织事实。
当文档、Spec、PR、Commit、反馈、Release和事故，都能被转成统一协议下的Context，Agent就不再只是在局部工具里工作。
它可以搜索组织事实，读取受控正文，回到原始来源，并在权限范围内完成Deep Dive。
个人AI工具要变成组织能力，第一步就是让Agent真正拥有组织上下文。
