AI Native 架构：有限上下文、确定性边界与质量闸门

AI Native 的关键不是让模型替代一切，而是重新划定确定性逻辑、模型运行时与质量闸门的边界。
原文链接：AI 小老六

导语

AI Native 架构最容易被讲成一个很大的概念：模型会写代码、会调工具、会看页面、会自己规划任务，于是软件形态都要重来。这个判断方向没错，但如果直接从“未来应用长什么样”开始讨论，很容易滑向想象。

更稳的切口是回到一个具体问题：当人把一句模糊需求交给系统时，系统到底怎样把它变成可靠结果？

假设一个产品经理看完一批用户反馈后提出需求：“帮我判断最近差评是不是主要集中在新版本的搜索体验上。”这句话对人很自然，对计算机却不够精确。传统软件必须先把它翻译成一组确定性查询和统计逻辑：

SELECT
  app_version,
  feature_area,
  COUNT(*) AS negative_feedback_count
FROM user_feedback
WHERE sentiment = 'negative'
  AND created_at >= CURRENT_DATE - INTERVAL '7 days'
  AND (content LIKE '%搜索%' OR feature_area = 'search')
GROUP BY app_version, feature_area
ORDER BY negative_feedback_count DESC;

过去，这层翻译由程序员、脚本、运维工具完成。大模型进入后，链路出现了两条路线：一条是让模型把意图编译成确定性程序，另一条是让模型直接读取材料并推理出答案。

图：自然语言意图在确定性执行与模型推理之间的两条路径

这两条路线都会长期存在。确定性程序适合核心状态变更，模型推理适合意图理解、非结构化数据处理和长尾判断。AI Native 架构的核心，不是二选一，而是重新划分两者的边界。

两条路线：翻译层与运行时

路径 A 把大模型放在“翻译层”：人说自然语言，模型生成代码、SQL、命令或配置，最后仍由传统计算机执行。这里的输出是确定性代码，可测试、可回放、可审计。

路径 B 把大模型放进“运行时”：模型不只是生成程序，而是直接参与响应。它读上下文、调用工具、综合证据，最后给出一个概率性结论。这里的输出不是严格函数，而是一个分布。

维度	路径 A：意图编译	路径 B：执行推理
模型角色	离线翻译层	在线运行时组件
核心产物	确定性代码或命令	概率性结论或动作
适用场景	资金、库存、交易、发布等强一致性链路	客服、检索、分析、研究、非结构化处理
验证方式	类型、单测、CI、流量回放	Eval、Guardrails、抽检、权限边界
主要风险	生成的程序改坏确定性逻辑	结论不稳定、幻觉、越权调用

真正的工程难点，是在同一个系统里同时容纳这两种东西：靠确定性逻辑兜住核心状态，用模型能力吸收模糊意图和非结构化复杂度。

架构第一性：从有限心智到有限上下文

图：有限上下文窗口推动系统重新切分边界

传统架构设计的第一性目标是管理复杂度。抽象、封装、分层、限界上下文、模块边界，本质上都是认知压缩机制：人脑无法一次装下全部系统，所以必须切分、索引、过滤、按需加载。

大模型面对的是同一个问题，只是主语变了。过去是“用有限心智驾驭无限复杂度”，现在是“用有限上下文窗口驾驭无限复杂度”。

Transformer 的自注意力让模型可以在上下文内建立全局关联，但代价会随输入长度快速上升。粗略看，序列长度为 N、隐藏维度为 d 时，自注意力计算复杂度接近：

O(N² · d)

这意味着上下文不是免费的。哪怕窗口扩到 1M token，把所有东西塞进去也会带来延迟、成本和注意力稀释。架构仍然需要切分，只是切分的理由从“人读不动”变成了“模型窗口、成本和注意力不该被浪费”。

Agent-Friendly 代码：切分粒度可以更粗

模型和人类程序员的第一个差异，是上下文窗口更大。人一次只能稳定处理少量文件和函数，模型却可以横跨几十个文件做命名统一、调用链梳理和局部重构。

这会改变一部分架构习惯。过去为了迁就人脑，我们会把一个概念拆成很多小文件、接口、工厂、策略和适配层。对模型来说，过度中介反而会增加跳转次数，让每一次理解都消耗更多 token。

AI 友好的代码不一定更碎。一个能独立表达业务概念的模块，放在一个高内聚文件里，可能比硬拆成五层目录更容易被模型理解。真正需要保留的不是“文件越小越好”，而是“边界清晰、信息密度高、依赖关系少”。

旧标准	更适合 Agent 的标准
文件短，函数短，层次多	概念完整，边界清楚，少无效跳转
为未来扩展预留抽象	有真实多实现时再抽象
依赖人工心智模型理解约定	用命名、Schema、目录结构直接表达约束
文档补充代码含义	代码本身尽量自描述，文档只记录代码表达不了的决策

切分仍然必要，只是粒度可以更粗，时机可以更晚。

外挂记忆：隐性知识必须显性化

人类开发者会在项目里形成心智模型：哪些模块容易出问题，某个字段为什么不能改，历史上哪次重构踩过坑。这些知识很多不在代码里，却会影响判断。

Agent 没有这种稳定的团队默契。它下一次进入项目时，只能依赖两类东西：显式写在文件里的信息，以及工具能拉回来的信息，比如 git log、测试结果、目录结构、配置和文档。

因此，AI 友好的架构必须减少隐性知识：

层级	做法	价值	风险
L1 对话补背景	每次让人重新解释约束	启动简单	每次重来，知识不沉淀
L2 全局记忆文件	`AGENTS.md` / `CLAUDE.md` 汇总项目规则	比口头解释稳定	文件膨胀后注意力稀释
L3 模块级记忆	根目录放全局约束，子目录放局部约定	约束跟代码边界一起演化	需要维护规范
L4 自演化记忆	Agent 在任务后补充、修订、清理经验	能沉淀踩坑记录	可能出现记忆漂移和冲突

记忆文件不是越多越好。它只应该承载代码无法表达的内容：历史决策、跨系统协议、不能从类型推导出的业务约束、曾经踩过的坑。否则记忆系统本身会变成新的复杂度来源。

工具触手：Agent 看不见就无法推理

人类开发者的信息触手很长：可以看监控、翻日志、找产品补背景、问老同事、登环境排查。Agent 的触手取决于我们暴露了哪些工具。一个状态如果没有 API、CLI、MCP 或结构化日志，模型就等于看不见。

这对基础设施提出两个要求。

第一，可观测性要接口友好。给人看的 Dashboard 不够，Agent 需要可查询的指标、结构化日志、状态 API 和可复现的诊断命令。只把图画在页面上，模型很难稳定消费。

第二，数据维度要足够贴近业务。只有 QPS、延迟、错误率这些系统指标，Agent 只能看到现象；如果能同时拿到店铺、商品、用户、链路标签、流量类型，它才有机会拼出现场，做根因分析。

GUI 操作可以作为补丁。多模态能力提升后，Agent 确实可以打开浏览器读页面、点按钮、看图表，但这条路线成本高、稳定性差、速度慢。长期看，结构化接口仍然是更可靠的 Agent 入口。

信任问题：能力不等于可放权

人类程序员能合代码、能上线，不只是因为能力强，还因为背后有责任体系：Code Review、变更审批、灰度发布、故障复盘、责任人追踪。责任会反过来约束行为。

Agent 没有同样的责任结构。它无法真正签字，也无法承担事故后果。于是一个很现实的问题出现了：什么系统可以让 Agent 自己改、自己发？

答案不取决于系统复杂度，而取决于出错代价和保障能力。

系统类型	是否适合高自主度 Agent	原因
内部低风险工具	可以更激进	出错成本可承受
核心交易链路且保障薄弱	不适合	代价过高，责任链缺位
核心链路但保障极强	可以逐步放权	有回放、灰度、监控、回滚等多道闸门

无人驾驶列车是一个很好的类比。它不是因为“司机换成系统”就降低基础设施要求，恰恰相反，线路封闭性、信号系统、通信冗余、供电保障、监控能力都要更强。无人驾驶的可行性来自基础设施的确定性冗余。

Agent 也是一样。要让它接管更多变更，不能只追求模型永不出错，而要把错误挡在更靠左的位置；挡不住时，也要能灰度、回滚、降级、限流，把影响面压住。

质量闸门：AI Native 最该重投入的地方

图：质量闸门把 Agent 错误挡在进入生产之前

当 Agent 自主度提高，质量闸门要更厚，而不是更薄。越靠左的闸门成本越低，越靠右的闸门越接近真实世界，成本更高但兜底能力更强。

阶段	闸门	主要作用
编码期	强类型、Schema、Lint、ArchUnit	拦住形状错误和跨层违规
提交期	单元测试、AI Code Review	拦住已知行为错误和明显缺陷
合入期	生产流量回放	拦住真实分布下的行为回归
发布期	灰度、影子流量、Canary	控制影响面
运行期	报警、SLO、自动回滚、降级、限流	事故发生后快速止损

其中，生产流量回放可能是当前性价比最高的质量手段。它不像完整形式化方法那样昂贵，却能借用真实线上行为作为最强 Spec。

维度	模型检测	生产流量回放
穷举对象	抽象状态空间	真实流量分布
反例形态	导致属性失败的执行路径	新旧版本响应 Diff
规约来源	人工编写模型与性质	线上旧版本行为
成本	高，适合关键系统	中，适合更大范围工程落地

流量回放不是银弹。它覆盖不了没有历史流量的新功能，也抓不到流量未覆盖的边角路径。但在存量系统上，它是把 Agent 改动放进生产前最接近真实世界的一道闸门。

待测件拆小：让回放覆盖率变得可承受

流量回放的一个核心问题是覆盖不足。一个大服务里分支太多、状态太复杂，需要海量流量才能覆盖足够组合。解决思路不是一味加流量，而是把待测件变小。

图：通过业务边界和分层回放降低测试组合复杂度

原因很简单：测试组合数不是加法，而是乘法。一个函数里有 10 个独立开关，组合数是 2^10 = 1024；如果拆成两个互不影响的小函数，每个 5 个开关，总组合数就接近 2 × 2^5 = 64。

但拆小有前提：模块之间必须低耦合。如果共享状态、隐式依赖和跨模块副作用很多，单模块回放会误以为局部正确，集成后仍然出错。所以层内回放和端到端回放必须共存。

新功能没有流量：先存量，后增量

新需求没有历史流量，这是流量回放的天然盲区。可以缓解，但很难完全消除。

做法	价值	局限
借用相似功能流量	能覆盖主路径	边缘 case 仍然缺失
LLM 生成合成流量	能枚举边界条件	分布未必贴近真实线上
加厚右侧防线	灰度、监控、回滚兜底	不能提前发现所有问题

因此，AI 接管的优先级应该是先存量、后增量。存量链路有历史行为、真实流量和可对比基线，更适合提高 Agent 自主度；新功能阶段应该降低放权程度，靠更严格的人审、慢灰度和更厚运行期保护来兜底。

模型作为运行时：三条约束推导系统形态

当模型直接进入运行时，问题会变得更硬。所有架构约束都可以从三件事推出：

窗口有限：信息装不下，或者装进去也会被稀释。
推理成本近似随上下文平方增长：上下文越长，延迟和成本越高。
输出概率性：同一输入无法保证完全相同输出。

这三条约束会自然导出四类工程问题：

问题	约束来源	架构抓手
记忆分层	窗口有限 + 输出概率性	Working / Episodic / Semantic / Procedural Memory
多 Agent 编排	窗口有限 + 成本增长	拆窄上下文，控制信息传递
Eval 与 Guardrails	输出概率性	离线 Eval、在线抽检、输入/输出/行为防护
自主性与可控性	概率性 + 现实后果	Workflow 与 Agent 之间按风险调节

运行时 Agent 不能只靠“更大模型”。它需要记忆系统、工具协议、权限边界、评测体系和兜底策略共同支撑。

编排滑杆：Workflow 到全自主 Agent

Agent 系统的编排方式可以看成一根滑杆。左侧是预定义 Workflow，流程清晰、可控性高，但上限低；右侧是全自主 Agent，灵活性强，但可追溯性和稳定性更差。

图：从预定义 Workflow 到全自主 Agent 的编排滑杆

风险高、流程明确的场景应该偏左，例如金融、医疗、交易履约。长尾多、变化快、需要探索的场景可以偏右，例如客服、研究助手、内部知识分析。

随着模型基座增强，编排层会变薄。早期重型框架是在补模型能力不足；当模型能自己规划、反思、调工具，过厚的编排反而会变成负担。但“变薄”不等于“不要边界”，高风险动作仍然要放在权限、审批和回放之后。

效率与质量：AI Native 的两根主线

架构最终服务两件事：效率和质量。人类时代如此，AI Native 时代也一样。变化在于主语从程序员变成 Agent。

效率维度关注 Agent 能否更快理解系统、更快生成结果、更低成本协作：

子维度	核心问题	抓手
理解效率	Agent 多快读懂陌生系统	命名、目录、Schema、模块记忆
生成效率	Agent 写代码和调工具的吞吐	强模型、完备工具、Skill 化复用
协作效率	人与 Agent、多 Agent 之间怎么配合	任务拆分、上下文传递、抽检机制

质量维度关注 Agent 产物能否承担真实后果：

子维度	核心问题	抓手
正确性	行为是否符合预期	类型、Schema、测试、流量回放
韧性	出问题能否扛住	灰度、降级、限流、回滚
可解释性	出问题能否复盘	决策链路、工具轨迹、证据记录
安全性	是否会越权或被注入攻击	Prompt Injection 防护、权限边界、脱敏

核心判断：效率会折旧，质量要过度建设

很多效率类问题会被模型演进吃掉。更长上下文、原生长期记忆、更强 GUI 操作、更强工具调用，一旦进入模型基座，今天大量应用层脚手架都会迅速贬值。

质量类问题不会这么快消失。根因不在模型聪不聪明，而在真实世界需要有人承担后果。资金损失、客户投诉、生产事故、合规风险，都不是“模型能力提升”就能自动解决的东西。

所以，AI Native 架构当下最值得投入的方向不是把每个效率脚手架都做重，而是把质量防线做厚：让 Agent 更容易理解系统，也让它的错误更难进入生产；让它能做更多事，也让每一步都有证据、边界和回滚路径。

简化成一句话：效率类能力要做，但避免重资产化；质量类能力要过度建设，因为它决定了 Agent 最终能被放到多深的系统里。

AI小老六