友讯达：企业暂不涉及算力业务
2026-06-12 3351903
2026-06-12 0
这个系列会讲一些AI应用的事情，计划从演进方向到工程化应用，从问题到解决问题。 本篇会先讲述AI的问题与现在的主流方案。
AI应用在这里指的是AI Coding与LLM应用，在这几年的发展中，AI的应用一直有这不少的问题。 下面就上下文的演化进行说明。
从rules到skills、cowork再到harness。 ● 静默执行错误 AI在生成代码时，会根据上下文"脑补"一些不存在的信息。比如你给它一个API文档，它可能会"幻觉"出文档里根本没有的字段，然后基于这个幻觉继续编写调用代码。 这种情况下，代码看似正常跑通了，但实际逻辑完全跑偏。 静默执行错误认知行为，比如上下文幻觉，比如复杂上下文的信息丢失： 复杂任务的细节丢失，比如spec-kit生成的难以用来生成代码的产品白皮书和技术白皮书。
● 上下文信息丢失 现在AI Coding有一个头疼的上下文丢失现象，复杂项目做到后期，前面写过的设计决策、架构约定、业务规则"人间蒸发"。 也就是 Context Rot（上下文衰减），随着上下文窗口中的token增加，模型准确调用信息的能力会下降。
● 需求传递损耗 产品文档写得很好，但AI生成的代码完全不对味。或者分析的计划很好，但是执行计划的时候错漏百出。 比如Spec-Kit，从产品白皮书→技术方案→代码，这条信息传递链上存在巨大的语义损耗。
从Simple RAG到Multi Agent，从Prompt Engine到Context Program。 RAG我们需要大量的召回，维护知识库。 Multi Agent我们需要复杂的记忆架构、角色拆分来应对逐步爆炸切各Agent之间不一定同步的上下文。
这些问题，无一不在诉说着我们需要对上下文进行更高效的管理。 随着 AI 能力的提升，我们在用越来越少的上下文工程，做到越来越高效的事情。
这背后有一条清晰的工程化演进脉络： 从"对话内堆上下文"→ 到"系统侧编排上下文"。
从工程化的视角来看，AI Coding 与 LLM 应用的所有问题，本质上都可以归结为一件事：
早期的解法很直白：信息不够？塞进去。效果不好？再塞。
Prompt 里堆满了规则、示例、API 文档节选，上下文窗口越用越长， 模型却越来越"迷糊"——这就是典型的上下文膨胀陷阱。
真正稀缺的不是上下文长度，而是有效 Context 的组织能力。 LLM 能力越强，我们越敢于做"减法"。
现代上下文工程的核心，可以用四个维度来描述：
| 策略 | 含义 | 典型手段 |
|---|---|---|
| Offload（外置） | 将信息存到外部，不占窗口 | 向量库、知识图谱、外部记忆系统 |
| Retrieve（精召） | 按需精准检索，而非全量注入 | grep、LSP、语义搜索、结构化查询 |
| Reduce（压缩） | 对已有上下文进行智能摘要与裁剪 | 滑动窗口、摘要链、Token 预算管理 |
| Isolate（隔离） | 任务级别的上下文隔离，避免污染 | Skills、子 Agent、独立会话 |
正如 Claude Code 用 grep 替代全量向量检索——
正确的工具 + 精简上下文，远胜于冗长提示词堆砌。
当 LLM 不再被噪声淹没，静默执行错误、需求传递损耗等顽疾自然消解。 这正是"用更少上下文工程实现更高效能"的底层逻辑。
近几个月火爆的 Skills 与 Cowork 模式，正在让上下文越来越少、越来越纯粹。 因为不再需要 LLM 使用大量的上下文去推理，去分析在长对话后可能出现幻觉的问题， 而是将任务直接派发给一个预置了专项能力和极简上下文的 Skill。
● Skills（技能）：可以理解为一个个"即插即用"的微服务
每个 Skill 都高度专业化（例如 ReactComponentSkill、SQLQuerySkill），
其内部已经固化了执行特定任务所需的最核心指令和工具。
当 LLM 接到一个复杂请求时，它不再需要翻阅大量的 API 文档和历史对话来"学习"，
它只需要做一个简单的路由决策："这个任务应该调用哪个 Skill？"
● Cowork（协同）：这是 Skills 模式的自然延伸
当一个任务需要多个 Skills 协同时，一个轻量的"协调者"（Orchestrator）会出场。 它的上下文极其纯粹：只包含任务目标、可用的 Skills 列表以及它们之间的输入输出约定。 它不关心每个 Skill 内部是如何实现的，只负责按照工作流将它们串联起来。
这就好比一个项目经理，他不需要懂得如何敲代码或画设计图， 但他清楚地知道：应该先让设计师出稿，再让工程师开发，最后让测试验收。
● ClawBot：协同的更高形态——容错与接替
如果说 Cowork 是让多个 Skills 像团队一样"各司其职"， 那么 ClawBot 则是让这个团队具备了**"主动补位"**的能力。
它的核心思想是动态故障检测与任务重新路由：
ClawBot 的本质，是将传统 Agentic Loop 中"人工兜底"的部分，自动化地内建进了系统架构。
| 模式 | 核心逻辑 | 上下文特征 | 核心痛点解决 |
|---|---|---|---|
| Simple RAG | 向量匹配 Top-K | 碎片化、易丢失逻辑 | 补充外部静态知识 |
| Multi-Agent | 角色分工 + 状态机 | 冗余度高、同步难 | 处理跨模块复杂任务 |
| Skills/Cowork | 工具化 + 状态共享 | 精简、确定性高 | 消除推理幻觉，提升执行力 |
| ClawBot | Agentic Search（grep/LSP） | 按需加载、自验证 | 解决大规模工程的检索精度 |
很多"需要塞进上下文让模型现场推理的东西"， 被前置固化为可复用的能力 / 工具 / 流程， 从而让在线上下文更短、更稳定，执行速度和输出一致性更好。
这不是"上下文工程变少了"， 而是从对话内上下文迁移到了系统侧上下文编排（检索、记忆、路由、工具协调）， 仍然属于上下文工程的范畴。只不过，战场从 Prompt 窗口里，转移到了系统架构层。
用一句话总结这个趋势：
公司的 Aone Copilot 就很有潜力，是集成 Skills、Rules、McpServers 等配置的很好的平台。 它正在做的事，恰好是这套方法论的工程落地——把上下文的组织能力，沉淀进平台，而非每次都由开发者手工拼接。
本篇从工程化视角出发，梳理了 AI Coding 与 LLM 应用在上下文演化这条主线上的核心问题与主流方案：
问题侧：
方案侧：
Simple RAG → Multi-Agent → Skills/Cowork → ClawBot ↓ ↓ ↓ ↓ 全量召回 角色分工 工具路由 自主容错 （堆信息） （堆角色） （减上下文） （自愈系统）
趋势侧： 上下文工程的重心，从"对话内塞信息"转向"系统侧精准编排"。 越来越少的上下文，越来越高的执行确定性。
下一篇，我们将进入具体的工程化实践： 如何在真实项目中设计一套可落地的 Skills 体系？ 从 Skill 的定义、注册、路由，到多 Skill 协同的编排设计，以及踩过的那些真实的坑。