这是我在「Agent 实战营」里给到大家的一次「课程加餐」，和大家分享了我最近美国之行的一些一线见闻与真实感受。最后同学们也提了不少问题，我会在文章结尾整理出来，如果你也有类似困惑，希望能对你有所启发。
首先感谢 AWS 的邀请，让我有机会参加 AWS re:Invent 2025。在这次美国之行中，我不仅参加了这场全球顶级的技术大会，更有幸与 OpenAI、Anthropic、Google DeepMind 等硅谷顶级 AI 公司的多位一线从业者进行了深入交流，其中大多数观点都得到了不同公司专家的交叉验证。
2 万人的 NeurIPS 真的是超级大会，Gemini 一个展台周围就围成了这样
从 Las Vegas 的 re:Invent 会场，到 San Diego 的 NeurIPS，再到湾区的 AI 公司，十几天的密集交流让我学到了非常多。主要包括以下五个方面：
AI 辅助编程（Vibe Coding）的实践经验：分析了不同场景下效率提升的巨大差异，从创业公司的 3-5 倍提效，到大厂和研究机构效果有限的深层原因。
科学化的应用开发方法论：介绍了顶级 AI 应用公司普遍采用的 Rubric-based Evaluation 体系。
基座模型公司的组织与资源配置：深入分析了 Google、OpenAI、xAI、Anthropic 等公司的优劣势，包括算力资源、薪酬结构，以及模型团队与应用团队的合作现状。
创业公司的战略选择：基于资源和人才的现实约束，分析了创业公司应该避开的领域和应该专注的方向。
Context Engineering 的核心技术，讨论了应对 Context Rot 的关键技巧以及文件系统作为 Agent 交互总线的设计模式。
Vibe Coding（AI 编程）
1. AI 编程效果的两极分化现象
在与多家硅谷公司深入交流后，我们发现了一个重要共识：Vibe Coding 的效果呈现显著的两极分化。这种分化不是偶然的，而是由任务性质、组织类型、代码类型的根本差异所决定的。某些场景下，AI 编程能带来 4-5 倍 的效率提升，但在另一些场景中，AI 几乎帮不上忙，甚至会产生负面影响。
创业公司的 MVP 开发场景 是 AI 编程表现最为出色的领域。这种场景的核心特征是从 0 到 1 的原型开发，重点在于速度和寻找产品市场契合度（Product Market Fit，PMF），而非在复杂的现有系统上进行修修补补。创业公司通常使用 React、Django、FastAPI 等主流框架，而 AI 在这些技术栈上拥有充足的训练数据，能够直接生成大量的样板代码。更重要的是，创业团队规模较小，不需要跨部门协调，决策和执行都非常迅速，Code Review 流程也相对简单。在这种环境下，典型的 CRUD 业务逻辑、简单的 API 开发、前端表单和页面制作，以及数据处理脚本都能实现显著的效率提升。
一次性脚本和胶水代码（One-off Scripts 和 CRUD Code） 是另一个普遍适用的高效场景。无论是数据分析脚本、数据迁移工具、批量处理程序这样的一次性脚本，还是配置文件、数据转换层、API 调用封装、测试用例生成这样的样胶水代码，AI 都能发挥出色的作用。这类任务的共同特点是边界清晰、输入输出明确，不需要深入理解复杂的业务逻辑，即使出错影响范围也相对有限。值得一提的是，即使是 OpenAI、Google 的研究人员，也大量使用 AI 来编写这类代码。
然而，大厂的日常开发 却呈现出截然不同的结果。效率提升之所以有限，根本原因在于大厂工程师的时间分配结构：开会占用 30%，部门间扯皮协调占 20%，撰写文档占 20%，定位 Bug 占 15%，而真正的**编码时间仅占 15%**。AI 只能优化这最后 15% 的时间，对整体效率的影响自然有限。此外，大厂系统的复杂度极高，需要深入理解现有架构，涉及多个团队的代码库，还要考虑向后兼容性，AI 在这种环境下容易引入回归错误。严格的多轮 Code Review、各种 lint 检查、冗长的上线流程，也使得即便 AI 写得再快，后续流程的时间成本依然不变。
Research Code 代表了 AI 编程的能力边界。这类智力密集型代码包括修改模型架构（如 Attention 结构）、调整训练算法、优化数据配比等，往往只需要修改 3 行代码，但需要深思熟虑很久。由于这些都是前沿研究，训练数据中并没有相关内容，需要深厚的理论背景和创新思考，每个研究项目都具有独特性，不存在标准做法。因此，研究人员主要将 AI 用于编写辅助脚本，如数据分析和可视化，而将核心算法逻辑完全留给人类。
最后，核心基础设施代码 是一个需要格外谨慎的领域，用不好就是帮倒忙了。这类代码对性能极其敏感，要求极低的延迟和手动优化，而 AI 生成的代码通常不是最优的。同时，任何 Bug 都可能导致大规模系统故障，需要对边界情况有深入考虑，AI 容易遗漏关键的 corner cases。涉及认证、授权、加密、签名等安全关键逻辑时，更不能有任何疏漏。因此，这类代码最好还是由人来写。
2. 硅谷一线团队的 Vibe Coding 最佳实践
为了防止 AI 把代码写乱，我们结合硅谷多家公司的经验，总结出了一套成熟的工程化流程。这套流程的核心是将 AI 当作“不太靠谱的初级程序员”来管理，通过严格的约束和检查机制确保代码质量。
PR 行数限制 是整套流程的基础。单个 PR 必须严格控制在 500 行以内，这个限制对 AI 和人类都具有重要意义。对于 AI 而言，过长的上下文容易导致幻觉和逻辑崩坏，明确的任务边界能避免 AI “跑偏”，同时减少不同模块间的耦合风险。对于人类而言，500 行是 Code Review 的认知极限，超过这个数量，Review 质量会大幅下降。具体的标准会根据场景有所调整：后端和 Agent 核心代码严格限制在 500 行，前端 React 代码可以放宽到 2000 行，测试用例可以超过 500 行。要做到这一点，人的职责就变成了提前进行需求拆分和任务分解，这也是 Vibe Coding 中人的核心价值之一。
全自动化的多 Agent 协作工作流 代表了业界最先进的实践。当线上出现 Issue 或有新的功能需求时，系统会自动创建相应的 ticket，并触发 Coding Agent 开始编写代码。代码生成后不会直接提交 PR，而是自动触发 3-5 个不同的 Review Agents 并行执行，这些 Agents 使用不同的基座模型，部分甚至是购买的第三方 Code Review 服务。与此同时，系统会运行完整的自动化测试套件，包括单元测试和集成测试。只有当所有 Review Agents 都认为代码没有问题，且所有自动化测试通过时，系统才会自动生成 PR 并通知相关人员。最后，人类进行最终的审查，检查 AI 可能遗漏的业务逻辑问题，确认是否符合项目整体架构，并决定是否合并。对于简单问题，这个流程可以实现完全自动化，人只需要做最后的确认。
测试驱动的质量保障 是整个体系的安全网。核心理念是必须建立充足的测试覆盖，测试用例成为 AI 代码的保护屏障，没有测试的代码不允许 AI 随意修改。同时要保护测试用例本身，不能让 AI 随便删除或修改测试用例，防止 AI 为了“让测试通过”而删除测试。此外，还要建立内部的 Rubric-based Benchmark，评测标准（类似第六章讲的 Evaluation 方法），针对不同场景设定不同的评价指标，并通过自动化打分机制，快速验证每一次改动的效果。
对于无法在 500 行内完成的大型重构或新特性开发，则需要采用人机协作的方式。首先由人编写详细的技术设计文档，明确架构和模块划分，定义接口和数据流。然后根据设计文档拆分成多个子任务，确保每个子任务都控制在 500 行以内。在具体分工上，核心业务逻辑，对性能要求极高的部分、对业务理解要求很深的部分，以及涉及复杂架构决策的部分由人来完成；数据转换格式化、API 调用封装、重复性的 CRUD 操作、测试用例生成等边缘代码由 AI 负责。整个过程采用迭代方式，AI 先写一版，人 review 后决定保留或修改，逐步集成并持续测试。
顶级 AI 公司的应用开发：“科学方法论”
这次与 Google DeepMind、OpenAI 和 Anthropic 顶级 AI 公司应用开发团队的深入交流中，最令我震撼的是他们做应用的科学性和严谨性。这些公司不是在“试” Prompt，而是在“测”系统。虽然三家公司的具体实践有所差异，但核心理念高度一致：数据驱动、严格评估、持续迭代。
1. 严格的评估体系（Evaluation System）构建
顶级 AI 公司绝不会凭感觉上线应用，而是建立了完善的 Rubric-based Evaluation System（基于细则的评估体系）。这套体系的核心是对每个测试案例的每个指标进行自动化打分。任何版本在上线前，所有关键指标都必须达到预设的标准。如果某项指标无法达标，必须经过高层特别批准，并提交明确的后续整改计划。这种严格的标准确保了产品质量的稳定性和可预测性。
2. 数据飞轮与自动化迭代机制
测试数据集的构建和维护 是整个体系的基础。每个功能模块都配备专门的测试数据集，有专人负责根据线上出现的问题案例持续构造和维护数据集。一旦发现新问题，就会立即加入到测试数据集中，形成持续改进的闭环。
全自动化评测流程 通常需要几个小时来处理几百个测试案例，团队习惯于晚上提交任务，第二天早上查看结果。系统使用 LLM 作为评判者，每个评估指标都有专门的 Prompt 来进行判断，严格按照预定义的细则进行打分。虽然也会请人工标注数据来评价结果，但能够达到甚至超过 LLM Judge 水准的人工标注成本极其高昂。
3. 基础模型团队与应用团队的微妙关系
通过深入了解，我发现了一个重要现象：基座模型公司内部做应用本质上等同于外部创业公司做应用。模型团队的优先级排序非常明确：首先是四大通用 Benchmark（数学能力、代码能力、电脑操作、深度研究），其次是长期的模型智力提升和通用能力增强，这些被认为是对模型长远发展最重要的方向。而垂直领域的需求则排在极低的优先级上，基本不会得到响应。
这种优先级设定带来了一个有趣的结果：应用团队很难影响模型团队的发展方向。无论是内部应用团队还是外部创业公司，都面临着同样的限制：使用相同的基座模型 API，无法影响模型训练方向，无法要求针对性优化。
不过，基座模型公司的应用团队确实具有两个独特优势：一是可以更方便地找到模型团队来 Review Prompt，改进 Context Engineering；二是 Token 成本采用内部计价，比外部公司调用 API 便宜很多，这也解释了为什么 Cursor 的 API 成本远高于 Claude Code 的订阅费用。
相对而言，外部创业公司反而在某些方面更有优势：可以同时使用多家模型，而 Google 内部只能使用 Gemini；可以创建 Mashup Agent，将 OpenAI、Anthropic、Gemini 混合使用；在技术选型上更加灵活自由。
硅谷巨头众生相：优势、劣势与内幕
1. Google DeepMind：资源优势与组织效率的博弈
Google DeepMind 展现出了四大显著优势。
首先是创始人的高度重视和强大组织能力。ChatGPT 发布后，Google 联合创始人 Sergey Brin 亲自重返公司，DeepMind CEO Demis Hassabis 展现出卓越的技术和管理能力，成功将几千名顶尖人才凝聚在一起，避免了严重的内耗和政治斗争。虽然合并过程中存在一些摩擦，但整体团队向心力依然很强。这与其他公司形成鲜明对比：Meta 的扎克伯格将 AI 管理权下放给 Alexandar Wang，而后者不亲自管细节，又进一步下放给团队；微软和苹果的高层对 AI 技术细节的理解相对有限。Gemini App 被并入 DeepMind 的决策也体现了一个重要认知：做应用本质上就是研究工作，需要科学的方法论、大量实验和数据驱动，以及完善的评估体系。
其次是碾压性的算力资源优势。Google 采用 TPU 和 GPU 双轨战略，自研的 TPU 提供了持续稳定的算力供应，多年积累的 Nvidia GPU 采购也形成了雄厚基础，总算力可能是 OpenAI 的数倍。这种算力优势直接体现在模型规模上：OpenAI 的主力模型 GPT-4o 系列参数规模为几百 B，虽然经历了几代演进，但参数规模一直没有显著增加，主要通过测试时缩放（思维链）来提升能力。相比之下，Google 的 Gemini 2.5 Pro/3 Pro 拥有数 T 参数，比 OpenAI 主力模型大一个数量级，甚至 Gemini 3 Flash 的参数规模就与 GPT-4o 相当。OpenAI 之所以无法使用更大模型，主要受制于算力不足：训练和服务都需要大量资源，而 ChatGPT 作为行业标杆拥有超过 10 亿用户，API 调用量巨大。相比之下，Gemini 用户量约 6 亿，API 调用量约为 OpenAI 的 1/5，因此可以“任性”地使用更大的模型。
第三个优势是充足的人力资源配置。以图片生成模型为例，Google 的 Nano Banana Pro 算法团队不到 10 人，但数据和基础设施团队接近 1000 人；而 OpenAI 对应模型的算法团队同样不到 10 人，但数据加基础设施的人员数量差了一个数量级。人员充足的优势主要体现在能够针对特定场景构造大量训练数据，比如原理图、九宫格图片等，这些都需要大量人工标注和数据构造工作。当前的基座模型仍然高度依赖人类构造的数据，仅靠互联网数据远远不够。
第四个优势是生态入口的天然便利。Chrome 浏览器右上角直接集成了 Gemini 按钮，用户体验比 ChatGPT Atlas、Perplexity Comet 等独立浏览器插件更好，可以直接询问当前页面问题或总结长文。Google Workspace 的深度集成让 Gemini 可以直接操作 Calendar、Drive、Gmail 等核心应用，这些都是天然的用户基础。多年积累的 YouTube 视频数据为多模态训练提供了宝贵资源，Google Search 直接展示 AI 摘要也成为了新的流量入口。
然而，Google 也面临两个明显的短板。
首先是大公司固有的效率问题。复杂的流程使得数据集构建、评估体系建立需要大量时间，产品迭代速度远不如创业公司，甚至连 OpenAI 这样的中型公司迭代速度都比 Google 快。内部人员最担心的就是 OpenAI 和创业公司的速度优势，虽然自身资源丰富，但“船大难调头”的问题始终存在。
其次是只优化通用需求，不涉足垂直领域的战略局限。模型团队的优先级排序非常明确：通用 Benchmark 第一，模型智力和长期能力提升第二，垂直领域需求基本没有精力响应。这种策略对创业公司而言反而是机会窗口，因为垂直领域需要大量 Context Engineering 工作，不是通用数据飞轮就能解决的，而且我们使用的模型与 Gemini App 团队使用的完全相同，技术起点是平等的。
2. OpenAI：品牌光环下的多重焦虑
OpenAI 虽然拥有 AI 领域最强的品牌认知度，堪称 AI 界的“扛把子”，但内部实际上承受着巨大压力，对 Google 的追赶感到非常焦虑。Google 在资源、算力、数据等方面都占据优势地位，这种压力感在公司内部非常明显。
人才结构问题 是 OpenAI 面临的一个重要挑战。公司招聘了太多学术背景的人员，导致学术思维与工程思维之间产生冲突。学术人员希望验证自己的学术想法，但这些想法在工程实践中可能并不实用，这在注重结果导向的 xAI 绝对不会发生。2023 年 Ilya Sutskever 等核心科学家的离职，主要原因就是认为 Sam Altman 的资源分配不公：太多资源用于服务线上用户，而训练新模型的资源不足。
算力资源困境 是 OpenAI 面临的核心矛盾。作为拥有超过 10 亿用户的平台，OpenAI 必须在有限的算力下在训练和服务之间做出平衡。这种资源约束导致了一些用户体验上的妥协：早期 ChatGPT Plus（20 美元/月）采用暴力截断上下文，Context Window 仅有 32k tokens，导致严重的幻觉问题——丢失前面的上下文后，后续输出完全是胡说八道。大小模型路由策略也引起了争议：GPT-5 实施自动路由，让小问题使用小模型，但路由准确性不足，重要问题可能被分配给小模型，而用户无法看到具体是哪个模型在回答，导致体验下降和用户投诉。
不过，OpenAI 在 Codex 方面确实做得出色，代码生成能力很强，针对真实使用场景进行了大量优化，而不仅仅是针对 Benchmark 进行调优。
3. xAI：极致效率与零容忍文化
xAI 展现出了与其他公司截然不同的企业文化。Elon Musk 明确宣示：“我们没有 Research Engineer，只有 Engineer”（No Research Engineer, only Engineer），意思是不要进行学术研究，只要工程结果。这与 OpenAI 形成鲜明对比——OpenAI 有大量学术背景人员浪费资源尝试论文中的想法，导致工程交付延迟，而 xAI 绝不允许这种情况发生。
工作强度 是 xAI 的另一个显著特征。全员每周工作 70 小时以上是常态，体现了“绝不让机器等人”的企业文化。工程师经常在深夜 12 点爬起来查看 Loss 曲线和各种指标，发现问题立即重新提交任务，否则第二天就会浪费十几个小时的训练时间。这种强度与其他公司形成对比：OpenAI、Anthropic、DeepMind 的核心团队普遍每周工作 60 多小时，Google 非核心部门甚至一周只上 3 天班。
4. Anthropic：聚焦策略与技术创新
Anthropic 采取了明确的战略聚焦，将 Coding 设为第一优先级，Agents（包括 Computer Use） 设为第二优先级。同时，Anthropic 一直在推广 Skills 机制（动态加载 Prompts），认为这是非常重要的 Agent 技术。
5. AI 人才战：史无前例的薪酬军备竞赛
硅谷 AI 行业的薪酬水平已经达到了令人震惊的程度。刚毕业的顶级 PhD 年薪包可达 150-200 万美元，条件是研究水平较高，虽然大部分是期权，但 OpenAI 已经足够大，可以兑现。在顶级 AI 公司有一定经验的算法工程师 年薪包达到 400-500 万美元，条件是在顶级 AI 公司有相关经验或有知名学术工作。Meta Super Intelligence 级别的大神 年薪包超过 1000 万美元，主要是 Meta 股票且可以兑现，“一亿美金招聘”的新闻确实属实。Meta 的 Super Intelligence 团队开始疯狂挖人，把整个市场的薪酬水平拉了起来。
AI 与非 AI 工程师之间的薪资差距 达到了惊人的 3-4 倍。非 AI 工程师年薪通常为 25-30 万美元（Google 正常水平），而 AI 工程师年薪超过 100 万美元。这意味着会 AI 和不会 AI 之间存在天壤之别的薪资差距，行业已经高度分化。
营销投入 也达到了前所未有的规模。从旧金山机场出来，高速公路两侧几十公里范围内，几百个广告牌基本都是 AI 公司的广告。Snowflake 等传统公司也在拼命讲 AI 故事，Redis 甚至打出了“My boss really wants you to know we're an AI company”（我老板非常想让大家知道我们是 AI 公司）这样的广告，所有公司都在向 AI 靠拢。
AI 人才战与当年团购大战的本质区别 非常明显。团购时代的钱主要花在招运营、做地推、打广告上，核心是抢市场、抢商户、抢用户，采用人海战术；而 AI 大战的钱主要花在招顶尖人才和购买 GPU 上，核心是训模型、拼算力、抢人才，采用精英战术。基座模型公司核心研究团队的人均算力配置达到 500-1000 张 GPU，人均薪酬超过百万美元，人的薪酬和硬件成本已经在同一数量级。
基座模型公司面临的资源困局 使得它们只能专注于“大事”。由于每个人的机会成本极高，必须做能够影响数亿用户的通用能力，不能让年薪几百万的员工去做垂直领域的小场景应用。垂直领域市场规模小，投入产出比算不过来，让年薪几百万的人做一个垂直行业显然不经济。因此，这些公司只能聚焦于数学、编程、电脑使用、深度研究等影响所有用户的基础能力，这才配得上他们的资源投入规模。这种现状为创业公司提供了重要的机会窗口。
6. 对创业公司的战略启示：如何在巨头夹缝中生存？
基于对硅谷巨头的深入观察，我总结出创业公司在 AI 时代的几条生存法则。
首先，绝对不要与基座模型公司正面硬碰。通用 Coding Agent、通用 Deep Research、通用 Computer Use 这些领域创业公司必败无疑。原因很简单：真正懂模型训练的人年薪极高，创业公司融资几百万到几千万美元，招几个人钱就没了；训练通用模型即使只是后训练也需要几百到几千张卡，创业公司根本租不起；通用能力需要海量高质量数据，大厂拥有 YouTube、Web Search 等生态优势，创业公司无法获得这些数据。除非含着金钥匙出生，否则不要碰通用领域。
其次，不要轻易涉足模型训练。真正懂模型的人都在大厂，不会轻易出来，创业公司根本挖不起；中等水平的人做不出竞争力，训练模型需要大量试错，新手很容易把钱烧光还训不出模型；开源模型加微调的策略也面临困境，开源模型质量比闭源模型差两个数量级，微调很难弥补这个差距，除非是极其偏门的垂直领域。只有在针对特定场景的小模型、领域比较偏门通用模型能力不足、有明确数据优势的情况下，才可以考虑训练。
第三，采用正确的人才战略。核心原则是招聘聪明、学习能力强但没有 AI 背景的人。这个策略之所以有效，是因为 AI 领域发展太快，复利效应较弱，最佳实践每 3-6 个月就变一次。新人可以快速走到前沿，聪明加学习能力强加肯钻研，6-12 个月就能达到业内中等偏上水平，不需要 PhD 学位和大厂背景，但成本优势巨大，相差 5-10 倍。
最后，保持正确的心态，等待你的 Wave。不要被 AI 人才的天价薪酬产生焦虑。每个人和公司都有不同的发展阶段，他们能拿高薪是因为赶上了这一波浪潮，在正确的时间做了正确的事情，积累的技能恰好匹配当前需求。关键是保持相关性：在没有机会的时候不要放弃，踏实打好基础；组建工程能力强、学习能力强、凝聚力强的团队；保持第一性原理思考，紧密跟踪最前沿的产品和研究；预判模型和产品趋势，当机会来临时已经准备就绪；能够快速开发产品并快速推向市场，在用户量增长时构建起数据飞轮。ChatGPT、Gemini App、Cursor 都拥有数据飞轮，这是成功的关键。
核心技术实践：Context Engineering 与文件系统
1. Context Engineering（上下文工程）
这是 Anthropic 团队重点强调的技术方向，也是我们和 Anthropic 专家在 re:Invent 会场深入讨论的核心话题。
Context Engineering 被定义为“优化 token 效用以对抗 LLM 固有约束的学科”（The discipline of optimizing the utility of tokens against the inherent constraints of LLMs）。这一定义揭示了在大语言模型应用中，如何高效利用有限的上下文空间来达成最佳性能的核心命题。
1.1 Context Engineering 的完整框架
Anthropic 提出了一个系统化的 Context Engineering 框架，该框架围绕四个核心维度展开，每个维度都有其独特的设计原则和实践方法。
维度一：System Prompt（系统提示）
在系统提示的设计中，核心原则可以概括为“Say less, mean more”，即“少说，但意思更明确”。这要求我们使用最少但最精准的指令来传达意图，采用清晰、简单、直接的语言进行表达。同时，内容需要以结构化的方式组织，并把握合适的抽象层次，既不能过于死板僵化，也不能流于模糊不清。
维度二：Tools（工具设计）
工具设计遵循“Every tool earns its place”的原则，意味着每个工具都必须证明其存在价值。优秀的工具应该是自包含且独立的，功能之间不存在重叠，目的明确清晰。此外，工具需要具备明确的参数定义、简洁清晰的描述，以及清晰可辨的成功和失败模式，让使用者能够准确预判工具的行为表现。
维度三：Data Retrieval（数据检索）
数据检索的核心原则是“Load what you need, when you need it”，即按需加载。这种理念体现在 JIT Context（Just-In-Time 上下文）的实践中，要求我们在预加载和动态获取之间找到平衡点。理想的系统应该允许 Agent 自主获取所需数据，通过设计良好的检索工具来实现这一目标。正如 Anthropic 的专家所言：“不要发送整个图书馆，发送一个图书管理员”（Don't send the entire library. Send a librarian），这生动地诠释了智能检索的精髓。
维度四：Long Horizon Optimizations（长期任务优化）
对于需要长时间执行的复杂任务，核心策略包括采用历史压缩策略（Compaction strategy）来管理不断增长的上下文，通过结构化的笔记记录（Structured note-taking）来保存关键信息，以及在适当时机使用 Sub-Agent 架构来分解复杂任务。这些策略共同确保了系统在长期运行中保持稳定和高效。
1.2 Data Retrieval 的范式转变
在数据检索领域，正在发生一场从传统方法到现代方法的重要转变。传统的 Pre-Loading 方法（也就是传统的 RAG 方式）倾向于预先加载所有可能相关的数据，这种做法虽然简单直接，但往往导致大量无用信息占据宝贵的上下文空间。
新的 Just-In-Time 即时加载方法代表了 Context Engineering 最重要的转变之一，它包含三个核心策略。
策略一：Lightweight Identifiers（轻量级标识符）
这一策略的核心理念是传递 ID 而非完整对象，Agent 只在真正需要时才请求详细信息。举例来说，系统可以传递 user_id: "12345" 这样的标识符，当 Agent 需要完整信息时再调用 get_user() 函数来获取完整的用户资料。这种方式大大减少了不必要的数据传输。
策略二：Progressive Disclosure（渐进式披露）
渐进式披露强调从摘要信息开始，让 Agent 根据实际需要逐步深入探索。典型的应用场景是文件处理流程：先展示文件列表，需要时再提供文件元数据，最后才加载完整的文件内容。这种层层递进的方式既保证了信息的可得性，又避免了信息过载。
策略三：Autonomous Exploration（自主探索）
自主探索的理念是提供发现工具，而非直接进行数据转储。这种 Agentic Search 的方式让 Agent 能够自主导航信息空间，主动寻找所需信息。例如，系统可以提供 search_docs() 和 read_doc(detail_level)这样的工具，而不是一次性加载所有文档。这赋予了 Agent 更大的自主权和灵活性。
1.3 Context Window 与 Context Rot
Context Window 的限制：
所有前沿的大语言模型都面临着一个根本性限制：单次交互能处理的最大 token 数是有限的。以 Anthropic 为例，其 context window 容量为 200k tokens。
什么是 Context Rot（上下文腐化）？
然而，即使在这个限制范围内，随着上下文的不断增长，输出质量也会出现下降趋势，这种现象被称为 Context Rot（上下文腐化）。
上下文腐化的产生源于多个相互关联的因素。首先是 Context Poisoning（上下文污染），当上下文中存在相互冲突的信息时，模型的推理能力会受到破坏。其次是 Context Distraction（上下文干扰），过多无关信息会转移模型的注意力，使其难以聚焦于真正重要的内容。第三个因素是 Context Confusion（上下文混淆），当上下文中存在大量相似项时，模型对这些信息的区分能力会变得模糊。最后是 Context Clash（上下文冲突），当不同指令之间存在相互矛盾时，模型将难以决定遵循哪一条指令。
研究结论：
Chroma 的技术报告《Context-Rot: How Increasing Input Tokens Impacts LLM Performance》的研究结论表明，所有模型在处理长上下文时都会出现性能下降，这是一个普遍存在的挑战。
1.4 三种长期任务策略
当任务的复杂度超过 context window 容量时，我们需要采用特殊的策略来应对。Anthropic 提出了三种行之有效的解决方案。
策略一：Compaction（压缩）
压缩策略的核心做法是定期总结中间步骤，并对历史信息进行压缩处理。系统会用压缩后的摘要来重置上下文，只保留关键信息以供后续使用。这种方法的权衡在于，我们需要牺牲部分细节来换取系统持续运行的能力。例如，与其保留完整的对话历史，不如压缩为“用户想要 X，尝试了 Y，学到了 Z”这样的精炼摘要。
策略二：Structured Memory/Note-taking（结构化记忆/笔记）
结构化记忆策略让 Agent 维护显式的记忆工件，这些工件存储在外部的持久化存储中。Agent 可以在这些“工作笔记”中记录决策过程、关键学习和当前状态，所有信息都以结构化格式保存。当需要时，系统按需检索这些信息，而不是将所有内容都保留在上下文中。典型的应用包括决策日志和关键发现文档，这些文档成为 Agent 的“外部大脑”。
策略三：Sub-Agent Architectures（子代理架构）
子代理架构通过将复杂任务分解为多个专门的 Agent 来应对挑战。每个 Sub-Agent 都拥有专注、清晰、狭窄的上下文，只负责特定的子任务。Main Agent 则负责编排整个流程并综合各个 Sub-Agent 的结果。例如，一个代码审查 Agent 可以启动专门的文档检查 Sub-Agent 来处理特定的审查任务。
1.5 Skills 机制的工作原理
什么是 Skills？
Skills 是包含指令、脚本和资源的组织化文件夹，Claude 可以动态发现和加载。
Progressive Disclosure 的实现：
pdf/SKILL.md (主文件)
├── YAML Frontmatter (name, description)
├── Overview (概述)
└── References: "For advanced features, see /reference.md"
pdf/reference.md (详细参考)
└── Advanced PDF processing features...
pdf/forms.md (专门功能)
└── PDF form filling instructions...在这个结构中，Claude 可以根据需要导航并发现更多细节。Discovery 机制让 Claude 能够逐步深入探索，而 Executable Scripts 则提供了 token 高效性，对于那些用传统代码更好完成的操作，这种方式提供了确定性和可靠性。
Skills 在不同产品中的应用方式也各有特色。在 Apps 中，Skills 会被自动调用，提供最佳的用户体验。在 Developer Platform 上，开发者可以通过 Code Execution API 将 Skills 部署到产品中。而在 Claude Code 环境中，Skills 同样会被自动调用，特别适合开发者的工作流程。
1.6 Tool Design 最佳实践
优秀的工具设计需要兼顾多个要素。首先，工具应该有简单准确的名称，让使用者一目了然。其次，需要提供详细且格式良好的描述，包含工具返回什么信息、如何正确使用等关键说明。
在设计多个工具时，必须避免过于相似的工具名称或描述，以免造成混淆。实践表明，工具执行单一操作时效果最好，参数嵌套层次尽量控制在一层以内。提供清晰的示例也至关重要，这些示例应该展示期望的输入和输出格式。同时，开发者需要注意工具结果的格式化，确保返回的信息易于理解和处理。最后但同样重要的是，必须对工具进行充分测试，确保 Agent 能够很好地使用它们。
1.7 Context Engineering 的实战案例
案例 1：Deep Research Agent
Deep Research Agent 面临的挑战极具代表性：它需要阅读和分析大量文档，需要进行多轮搜索和分析，在这个过程中，Context 很容易出现爆炸式增长。
通过应用 Progressive Disclosure 原则，这个问题得到了有效解决。整个流程被分为三个阶段：在第一阶段（搜索），Main Agent 负责规划整体的搜索策略。在第二阶段（分析），系统启动多个 Sub-Agent 来分析每篇文档。这些 Sub-Agent 只接收文档 ID 和分析目标这样的轻量级标识符，只在需要时才读取完整文档内容。在第三阶段（综合），一个全新的 Agent 负责综合所有分析结果。这个 Agent 读取所有 Sub-Agent 写入的分析文件（这体现了 Structured Memory 的应用），最终生成完整的研究报告。
案例 2：Coding Agent
Coding Agent 是 Context Engineering 框架的完美应用示范。在 System Prompt 层面，它包含明确的编码规范和架构指引。在 Tools 层面，它配备了 ls、read、write、edit、grep、bash 等自包含的工具。在 Data Retrieval 层面，它通过 grep 和 search 工具按需加载文件，而不是预加载整个代码库。在 Long Horizon 层面，它利用文件系统记录决策和状态，使用 Sub-Agent 处理独立的文件修改任务。
1.8 有效建立和维护上下文的收益
挑战 | 解决方案 | 收益 |
|---|---|---|
Handle context window limits | Compaction, Sub-Agents, Structured Memory | Reliability（可靠性） |
Reduce context rot | Progressive Disclosure, JIT Loading | Accuracy（准确性） |
Optimize for prompt caching | Structure context properly | Cost & Latency（成本与延迟） |
1.9 不同模型的 Context Engineering 策略
不同的大语言模型对 Context Engineering 的响应方式存在显著差异，这要求我们根据具体模型调整策略。
Claude (Anthropic)：
对于 Claude（Anthropic）而言，优先使用 Skills 机制能够取得最佳效果。动态加载 Prompts 在 Claude 上表现优异，因为该模型在训练时专门针对动态上下文更新场景进行了优化，天然支持 Progressive Disclosure 的理念。
GPT (OpenAI) 和 Gemini (Google)：
相比之下，GPT（OpenAI）和 Gemini（Google）则不推荐使用动态加载方式，因为效果不够理想。对于这些模型，更好的实践是在开头的 System Prompt 中明确定义所有规则。当需要引入新规则时，建议采用总结当前状态并启动新 Agent 的方式。不过，Sub-Agent 架构用于隔离任务在这些模型上同样有效，Progressive Disclosure 和 JIT Loading 等策略依然适用。
通用建议：
通用的建议是充分利用每个模型的特性，不要生搬硬套其他模型的最佳实践。虽然四个维度的框架（System Prompt、Tools、Data Retrieval、Long Horizon）是普适的，但在具体实施时需要根据场景选择最合适的模型和策略。
2. 文件系统作为 Agent 的交互总线
Anthropic 提出了一个颇具洞见的观点：Coding Agent 是所有通用 Agent 的基础。这一观点得到了业界的广泛认同，Manus 在一篇关于上下文工程的经典文章中也指出，文件系统是 Agent 架构的核心组成部分。
3. 为什么要用文件系统？
要理解文件系统的重要性，我们首先需要认识到 Tool Call 一次性输出大量内容所带来的问题。
Tool Call 一次输出大量内容的问题：
从稳定性角度看，当 Tool Call 需要一次性输出几百行内容时，如果中途发生中断，之前所做的所有工作都会付诸东流，无法实现断点恢复。从迭代性角度看，Tool Call 的输出是一次性的，无法进行修改。如果想要改动其中某一段内容，就必须重新生成全部内容，这使得“草稿-修改-定稿”这样自然的工作流程难以实现。
文件系统的优势：
文件系统则完美地解决了这些问题。从持久化的角度看，内容一旦写入文件就会被永久保存，即使 Agent 崩溃，文件依然存在，可以随时恢复并继续工作。从可迭代性的角度看，我们可以读取文件内容，修改其中的某一部分，可以多次修改并逐步完善，这种工作方式就像人类撰写文档一样自然流畅。
文件系统还具有出色的通用性。无论是 ls 命令用于列出文件，read_file 用于读取内容，write_file用于写入内容，edit_file 用于修改内容，还是 delete_file 用于删除文件，所有主流的大语言模型都能理解并正确执行这些操作。这种普遍的兼容性使得基于文件系统的 Agent 架构具有极强的可移植性。
3.1 Coding Agent 作为基础能力
当我们谈论 Coding 作为基础能力时，需要理解这里的“Coding”是广义的概念。
为什么说 Coding 是基础？
它不仅仅指编写 Python 或 Java 代码，更包括撰写文档、生成报告以及创建任何结构化内容。其核心本质在于对文件的读写和编辑操作。
Deep Research 的案例：
Deep Research 的案例生动地展示了这一理念。当系统需要生成一份长篇研究报告时，错误的做法是尝试用 Tool Call 一次性输出整个报告。这种方式面临的问题是，几千行的内容输出过程容易中断，而且写完之后无法进行修改。正确的做法是充分利用文件系统的能力：首先使用 write_file("report.md", ...) 写入第一章内容，然后进行更多调研，接着使用 append_file("report.md", ...) 添加第二章，如果发现第一章需要修改，可以随时使用 edit_file("report.md", ...) 进行调整。
所有主流模型都有很强的 Coding 能力
值得注意的是，所有主流的大语言模型都具备很强的 Coding 能力，这为基于文件系统的 Agent 架构提供了坚实的技术基础。
3.2 Main Agent 和 Sub-Agent 的信息传递
在 Agent 系统的架构设计中，一个关键问题是 Main Agent 和 Sub-Agent 之间如何高效地传递信息。
为什么用文件系统而不是函数调用？
相比于传统的函数调用方式，文件系统提供了更优雅的解决方案。函数调用方式存在明显的局限性：它需要序列化复杂的数据结构，字符串长度受到严格限制，整体灵活性不足。
文件系统的优势：
而文件系统则展现出明显的优势。在这种架构下，Main Agent 将任务描述和输入数据写入文件，Sub-Agent 读取这些文件，执行指定任务，然后将结果写回到新的文件中，最后 Main Agent 读取结果文件并继续执行下一步操作。这种方式建立了清晰的输入输出边界，就像 Unix 管道那样优雅而高效。
重点 Q&A 实录
Q1：垂直领域做微调（Finetune）还是用闭源模型？
经过深入分析，我的结论是：闭源模型 + Context Engineering > 开源模型 + Finetune。这个判断基于几个关键因素：闭源模型在知识密度、思维密度以及泛化能力方面都显著领先开源模型。闭源模型的 CoT（思维链）更加紧凑高效，而开源模型往往需要冗长的推理过程。只有在三种特殊情况下才建议考虑开源模型微调：领域极其偏门、数据隐私要求极高、或者成本极度敏感。需要特别注意的是，小模型（如 MiniMind）在处理复杂逻辑推理数据时很容易训练崩溃，这是一个需要谨慎考虑的技术风险。
Q2：个人化（Personalization）是真问题吗？
个人化绝对是真问题，而且是未来的核心竞争力。理想的 AI 应该能够适应每个用户的价值观和偏好，提供真正个性化的服务。然而，技术实现上存在显著的难度差异。事实信息（如生日、地址等）相对容易处理，但用户偏好（User Preference）极其困难。主要挑战在于用户偏好具有强烈的上下文依赖性，容易出现过度泛化的问题——比如用户的一次性行为被系统误认为是长期偏好。解决这个问题需要构建精细的 Evaluation 体系来平衡个性化程度，这是一个需要长期投入的技术方向。
Q3：端云协同 Agent 的前景和挑战？
端云协同是必然趋势，因为 Agent 需要在后台持续运行，而云端拥有更强大的算力资源。然而，核心挑战在于 APP 状态同步问题。这包括几个具体难点：登录状态冲突（如微信的单点登录限制）、IP 地址差异触发的风控机制、以及重复登录带来的用户体验问题。理想的解决方案是实现系统级状态同步，类似豆包手机采用的“影子系统”技术，或者更理想的操作系统级 APP 镜像同步机制。这需要在系统架构层面进行深度创新，而不是简单的应用层解决方案。
Q4：对我们使用 AI 写代码有什么建议？
核心原则是：人必须懂的比 AI 多。在 AI 编程时代，人的角色应该从 Coder 转变为 Architect + Reviewer。建议的工作流程是：由人进行需求拆解，确保单个任务控制在 500 行以内（前端可放宽至 2000 行），然后由 AI 进行具体的编码实现，接着运行自动化测试和多 Agent 代码 Review，最后由人进行 Final Review，重点检查业务逻辑合理性和整体架构一致性。这种分工能够最大化发挥人和 AI 的各自优势，同时确保代码质量和系统稳定性。
Q5：如何保证模型升级后工作流还能正常运行？
唯一的答案是建立完善的 Evaluation（评估体系）。这是因为基座模型的升级、Prompt 的调整都可能带来意想不到的变化，仅凭主观判断很难发现潜在的回归错误（Regression）。一套完整的评估体系应该包括：持续更新的测试数据集，能够覆盖各种边缘情况；基于细则（Rubric-based）的评估标准，确保评判的客观性和一致性；自动化运行和报告机制，及时发现问题；以及问题闭环优化流程，确保发现的问题得到有效解决。这种科学化的方法论是确保系统稳定性的唯一可靠途径。
Q6：如何获取 AI 前沿信息？
最推荐的渠道是 X(Twitter) 。这个平台是第一手论文发布、技术讨论和行业大佬分享见解的源头。很多国内的 AI 资讯账号的内容实际上也源自 Twitter 上的讨论和分享。Twitter 的实时性和开放性使其成为了解 AI 前沿动态最有效的平台，无论是新论文发布、技术突破、还是行业趋势讨论，都能在第一时间获得最新信息。
Q7：顾此失彼的 Prompt 怎么办？
这个问题有两个有效的解决方案。第一个解决方案是使用 Evaluation 防止 Regression。通过自动化评估体系，可以确保对 Prompt 的修改不会破坏现有功能，任何改动都需要通过完整的测试验证。第二个解决方案是结构化的 Prompt 组织。不要简单地堆砌规则，而是要像编写“新员工手册”一样，构建有层次结构和逻辑指导的 Prompt 体系，充分考虑各种情况和例外场景。这种结构化的方法能够减少规则间的冲突，提高系统的稳定性和可维护性。
如果你对文中这些实践细节本身就很感兴趣，想知道它们在真实项目里是怎么一步步落地的，我的 Agent 实战营以及正在写的新书，基本就是围绕这些场景展开的系统整理。期待你的加入！
扫一扫
4
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
