tinkphp5网站开发企业营销策划实现的途径

tinkphp5网站开发,企业营销策划实现的途径,遂宁市建设银行网站,设计手机网站建设这是我在「Agent 实战营」里给到大家的一次「课程加餐」#xff0c;和大家分享了我最近美国之行的一些一线见闻与真实感受。最后同学们也提了不少问题#xff0c;我会在文章结尾整理出来#xff0c;如果你也有类似困惑#xff0c;希望能对你有所启发。首先感谢 AWS 的邀请和大家分享了我最近美国之行的一些一线见闻与真实感受。最后同学们也提了不少问题我会在文章结尾整理出来如果你也有类似困惑希望能对你有所启发。首先感谢 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 CodingAI 编程1. AI 编程效果的两极分化现象在与多家硅谷公司深入交流后我们发现了一个重要共识Vibe Coding 的效果呈现显著的两极分化。这种分化不是偶然的而是由任务性质、组织类型、代码类型的根本差异所决定的。某些场景下AI 编程能带来4-5 倍的效率提升但在另一些场景中AI 几乎帮不上忙甚至会产生负面影响。创业公司的 MVP 开发场景是 AI 编程表现最为出色的领域。这种场景的核心特征是从 0 到 1 的原型开发重点在于速度和寻找产品市场契合度Product Market FitPMF而非在复杂的现有系统上进行修修补补。创业公司通常使用 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 Plus20 美元/月采用暴力截断上下文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 were 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 ContextJust-In-Time 上下文的实践中要求我们在预加载和动态获取之间找到平衡点。理想的系统应该允许 Agent 自主获取所需数据通过设计良好的检索工具来实现这一目标。正如 Anthropic 的专家所言“不要发送整个图书馆发送一个图书管理员”Dont 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 RotContext 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 机制的工作原理什么是 SkillsSkills 是包含指令、脚本和资源的组织化文件夹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 的实战案例案例 1Deep Research AgentDeep Research Agent 面临的挑战极具代表性它需要阅读和分析大量文档需要进行多轮搜索和分析在这个过程中Context 很容易出现爆炸式增长。通过应用 Progressive Disclosure 原则这个问题得到了有效解决。整个流程被分为三个阶段在第一阶段搜索Main Agent 负责规划整体的搜索策略。在第二阶段分析系统启动多个 Sub-Agent 来分析每篇文档。这些 Sub-Agent 只接收文档 ID 和分析目标这样的轻量级标识符只在需要时才读取完整文档内容。在第三阶段综合一个全新的 Agent 负责综合所有分析结果。这个 Agent 读取所有 Sub-Agent 写入的分析文件这体现了 Structured Memory 的应用最终生成完整的研究报告。案例 2Coding AgentCoding 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 limitsCompaction, Sub-Agents, Structured MemoryReliability可靠性Reduce context rotProgressive Disclosure, JIT LoadingAccuracy准确性Optimize for prompt cachingStructure context properlyCost Latency成本与延迟1.9 不同模型的 Context Engineering 策略不同的大语言模型对 Context Engineering 的响应方式存在显著差异这要求我们根据具体模型调整策略。Claude (Anthropic)对于 ClaudeAnthropic而言优先使用 Skills 机制能够取得最佳效果。动态加载 Prompts 在 Claude 上表现优异因为该模型在训练时专门针对动态上下文更新场景进行了优化天然支持 Progressive Disclosure 的理念。GPT (OpenAI) 和 Gemini (Google)相比之下GPTOpenAI和 GeminiGoogle则不推荐使用动态加载方式因为效果不够理想。对于这些模型更好的实践是在开头的 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 管道那样优雅而高效。重点 QA 实录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 实战营以及正在写的新书基本就是围绕这些场景展开的系统整理。期待你的加入