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

AI Native 的关键不是让模型替代一切而是重新划定确定性逻辑、模型运行时与质量闸门的边界。原文链接AI 小老六导语AI Native 架构最容易被讲成一个很大的概念模型会写代码、会调工具、会看页面、会自己规划任务于是软件形态都要重来。这个判断方向没错但如果直接从“未来应用长什么样”开始讨论很容易滑向想象。更稳的切口是回到一个具体问题当人把一句模糊需求交给系统时系统到底怎样把它变成可靠结果假设一个产品经理看完一批用户反馈后提出需求“帮我判断最近差评是不是主要集中在新版本的搜索体验上。”这句话对人很自然对计算机却不够精确。传统软件必须先把它翻译成一组确定性查询和统计逻辑SELECTapp_version,feature_area,COUNT(*)ASnegative_feedback_countFROMuser_feedbackWHEREsentimentnegativeANDcreated_atCURRENT_DATE-INTERVAL7 daysAND(contentLIKE%搜索%ORfeature_areasearch)GROUPBYapp_version,feature_areaORDERBYnegative_feedback_countDESC;过去这层翻译由程序员、脚本、运维工具完成。大模型进入后链路出现了两条路线一条是让模型把意图编译成确定性程序另一条是让模型直接读取材料并推理出答案。图自然语言意图在确定性执行与模型推理之间的两条路径这两条路线都会长期存在。确定性程序适合核心状态变更模型推理适合意图理解、非结构化数据处理和长尾判断。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 到全自主 AgentAgent 系统的编排方式可以看成一根滑杆。左侧是预定义 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 最终能被放到多深的系统里。推荐阅读Hermes Agent Skill Runtime 架构拆解让 AI Agent 不再从零开始GEPA 架构拆解让 Prompt 和 Skill 优化不靠玄学AI Native 竞争力真正稀缺的不是会用 AI而是把事往前推的人业务 Agent 搭建指南别急着重造 Agent用知识、工具与评测跑通闭环OpenClaw Dreaming 记忆流水线底层架构状态分层、证据留痕与检索回流