大模型基础知识

AI SIG
1

谁是工作流的核心

我们即将进入AI自动驾驶时代，当前还是辅助驾驶。

所谓辅助驾驶是什么意思？是AI辅助人嘛? 是人辅助AI。

那么在AI时代，我们势必要建立一套以AI为核心的工作流。

认识AI的核心

从第一性原理出发，当前的AI, 本质是LLM, 大语言模型, 本质是通过已有的数据, 预测下一个词(token)，因此，什么是AI的核心？

高质量的数据+算法是AI的核心。

软件上, 当前全部的AI公司, 做的无非就是两个方向, 如何提高模型能力, 以及如何提高信息编排能力.

前者是做模型的, 如GLM(质谱), Deepseek, GPT(openai), Claude(Anthropic), Gemini(google)

后者是做Agent的, 如ClaudeCode(Anthropic), Codex(openai), Antigravity(google)

信息不会凭空产生, 数据是第一性

从Microsoft GitHub copilet 到OpenAI GPT到DeepSeek，要训练出这样的模型，首先需要对高质量数据的收集和清洗。模型不是凭空产生信息的，信息是来自训练模型的语料。高质量的语料来自各大期刊、论文、社区、小说等等。

只有高质量的语料才能喂出高质量的AI。

什么是高质量？信息密度高的数据就是高质量。所以这是我们判断工作和数据好坏的核心–信息密度。

信息是向量, 是需要代谢的

同一个数据，不同的场景(上下文)下, 信息密度是不同的。也就是说, 信息, 是一个向量而不是 标量, 需要匹配到上下文的数据向量, 才是有效的信息。

同一个数据，对于不同的AI，信息密度是不同的。因为训练模型本身的语料可能已经包含了数据，因此重复输入不能带来有效的信息。因此，随着模型能力的提升和更多的语料输入，信息是需要代谢的。

信息密度可以一定程度从AI执行结果量化

幸运的是，信息密度虽然很难统计，但可以在AI时代转化成更直观的东西，AI执行的效果。

过去很多工作很难评价好与坏，尤其是软件开发这种过程性的工作，所谓的代码可读性，可修改性，方案的可扩展性，可执行性等等。但借由AI，我们可以一定程度量化衡量。

给定同样的交付件，使用同样的AI，把AI当成开发、当成测试，当成用户，AI越容易理解、AI生成效果越好的、AI执行落地越顺利、纠错次错越少、无监督运行越久、交付结果bug越少的交付件，信息密度越高，越好。当然对于我们软件开发领域大概是这样的。

但是同样地, 上文的代谢仍然生效, 当基础模型变化了, 一个交付件的信息密度也变了.

模型训练数据的特点

训练AI的语料，绝大部分具备以下特点

  • 结构化 xml json html markdown

  • 纯文本

  • 命令行 运行在linux/unix环境, 使用sh python js等命令行友好的语言

因此我们可以观察到，AI更善于输出这样的内容。

算法的特点

当前的LLM算法核心, 来自 Attention is all you need. 自注意力机制.

结构决定性质, 算法的特点和能力, 决定了当前AI 工程的特点和能力.

注意力机制的核心概念（简化版）：

  • 模型在处理一个序列时，让每个位置的Token“看一下”序列中所有其他Token（在因果模型中，只能看前面的），计算一个相关性分数。

  • 根据这些分数，加权聚合信息，帮助预测下一个Token。

  • 但请记住：模型内部只有矩阵乘法、Softmax等数值运算，没有任何真正的“理解”或“思考”。

  • 纯文本
    毕竟是语言模型

  • 并行计算，串行输出
    并行，指的是注意力的两两计算是并行的，串行，指的是每预测一个token，都需要依赖前面全部的上下文

  • 自注意力
    每一个位置的token都会影响注意力的分配，因此数据噪声直接影响了输出质量

  • N平方复杂度
    直接制约了AI的输出效率，直接导致了必须进行上下文管理；

  • 头尾注意力比较集中，lost in middle
    业界实测40%左右的上下文就会出现dumb zone, 原生限制了agent客户端必须做上下文管理；同时也是plan-with-files的方案(把todo加到开头和结尾)如此简单但如此好用统治业界的原因。

  • 概率性
    所有的结果都来自掷骰子

  • 无状态
    这里指推理时候模型参数已经固定，模型本身无状态，所有的输出都只随着输出和配置变化

当然，还有原生多模态（非纯文本）, 线性/混合注意力（线性复杂度而非平方），极大地提高了上下文，但承担核心工作、保证稳定输出的还是自注意力。

AI的特点

总结AI的特点如下

  • 数据上: 纯文本、结构化 决定了一切以AI为核心的工程的输入输出都应该优先选择纯文本, 结构化数据.

  • 算法上: 自注意力，无状态，串行概率输出，N平方复杂度、头尾注意力比较集中

所以，基于上述论述，当前的全部AI能力都来自大模型和提示词，所有的AI工程的本质都是这二者。

业界所有的上下文工程，包括harness工程，都是为了解决上下文编排的问题, 但都还没完全解决。

这里再一次强调一下! AI的组成部分就两个, 模型和上下文。模型一定的情况下，上下文，唯一决定了你的推理延迟、 输出 质量、 算力 **消耗、注意力窗口、缓存窗口和缓存命中。**所有的Agent工具拼了命, 要减少上下文的大小, 要提高上下文的信息密度.

上下文 IS ALL YOU NEED

模型是无状态的。每一次调用，模型都像第一次见到你一样，只根据当前输入的Token序列做出预测。

全世界所有的Agent工具、Harness框架、上下文工程，本质上都在解决同一个问题：如何构建一个高信息密度、低噪声、动态可扩展的上下文。

什么是上下文？说白了，就是提示词——但这里的“提示词”是广义的，包括系统指令、用户消息、工具定义、历史对话、外部检索结果、甚至是模型自己生成中间推理链。也就是，全部提供给模型的输入。下文将从历史演进的视角，梳理从最简单的Chat到完整Harness工程的每一层进化。

Chat：模型只会说话

LLM是一个概率语言模型，它的唯一能力是：给定一个Token序列，输出下一个Token的概率分布。它不会执行代码、不会查数据库、不会发邮件。
在Chat模式下，用户自己与模型对话、自己执行工具获取结果、自己把结果粘贴进对话框。这个就是原始的，人作为agent，参与AI的反馈循环。

本质上，模型也只会说话，从以前到以后，都是如此。

智能体（Agent）与提示词工程（Prompt Engineering）

为了让模型表现得像“某个领域的专家”，人们开始设计系统提示词（System Prompt），定义模型的角色、行为边界、输出格式。同时引入RAG（检索增强生成），从外部文档库中检索与当前问题相关的片段，拼接到上下文中。这就是最朴素的智能体雏形——一个“预定义提示词 + 外挂知识库 + 可选工具”的封装。

与之对应的是提示词工程：通过精心设计指令、少样本示例、思维链（CoT）等，引导模型输出更准确的结果。提示词工程的核心是静态优化——写好后就固定了，不能根据任务动态调整。

此时的上下文，由“固定的系统提示词 + 动态检索的文档片段 + 当前对话历史”拼接而成。缺点是：只能处理特定领域的问题，不会动态调用工具。

Tool Call / Function Call：结构化输出

模型只会说话，为了能让模型调用工具，业界定义了Tool Call（OpenAI风格）和Function Call（早期术语，现已基本统一）。模型输出结构化的JSON或XML工具调用指令，由agent工具解析输出，判定是否是工具调用，帮助AI调用工具，返回结果。也就是agent-client作为agent，参与AI的反馈循环。

当前Agent实践中，XML格式更受青睐，因为XML标签对（如 <function>、<parameter>）对注意力机制和概率性结果更友好。

Tool Call使得模型具备了“行动”的接口，但上下文仍然需要包含工具的定义（Schema）和调用历史。

Agent（广义与狭义）与上下文工程（Context Engineering）

Agent一词有两种含义，容易混淆：

  • 广义Agent（Agent客户端） ：指整个运行环境——它负责维护对话状态、管理工具、执行调用、处理权限、记录日志。例如Claude Code、OpenCode、Cursor等。

  • 狭义Agent（智能体定义） ：指封装在Agent客户端内部的“角色”，包含一组特定的提示词、工具集、权限范围、可调用的MCP Server或Skill。例如“代码审查Agent”、“数据分析Agent”、“旅行规划Agent”。

常见实现如 oh-my-opena gent 中的各个角色：每个角色是一个独立的Agent定义，拥有自己的系统提示词和工具白名单。

上下文工程 则是在提示词工程之上的演进。它不再只关注“怎么写系统提示词”，而是关注整个上下文的动态构建与管理，包括：

  • 动态检索与排序：从多个知识库中检索相关片段，并按相关性或Lost in the Middle原则排序（关键信息放头尾）。

  • 历史压缩：对过长的对话进行摘要，将压缩后的信息放回上下文，避免超出窗口。

  • 结构化注入：使用XML标签、Markdown表格、JSON结构来组织信息，降低模型解析难度。

  • 多模态转换：将图片、音视频先转成文本描述，再注入上下文。

上下文工程的目标是：在有限的上下文窗口中，最大化信息密度，最小化噪声。

到这里，agent-client扩展了模型的长任务能力，人类不再需要参与循环。

MCP（模型上下文协议）及其缺点

tool call是LLM说, agent调用本地的脚本/函数, 得到结果返回.

MCP是, 是LLM说, agent调用远程或本地的接口, 得到结果返回.

实现MCP接口的叫MCP Server, agent发起请求, Server返回执行结果.

当Agent连接多个MCP Server时，所有Server的工具定义、资源描述、提示模板都会被一次性全部注入到上下文中。这会导致：

  • 上下文窗口迅速被撑满（每个工具Schema动辄几百Token）。

  • 模型被迫在大量无关工具中“寻找”正确的那个，增加推理负担和出错概率。

  • 无法按需加载——即使当前对话只需要一个日历工具，所有数据库、邮件、文件系统的工具定义也都挤在上下文中。

这一问题直接催生了更精细的上下文管理机制，即Skill。

Skill：提示词的函数化与渐进式披露

Skill是对提示词（以及相关工具、资源）的模块化封装，可以像调用函数一样被Agent按需激活。一个Skill内部可以包含：

  • 一段特定的系统提示词（角色定义、任务指导）

  • 一组工具定义（或MCP Server引用）

  • 可选的外部资源（文档、脚本）

  • 子Skill的调用逻辑

为什么Skill如此好用？ 核心原因在于两个设计原则：

6.1 渐进式披露（Progressive Disclosure）

Agent不需要在启动时加载所有Skill。相反，它可以根据用户意图，先加载Skill的摘要（名称、简短描述、何时使用），只有当确定需要该Skill时，才将其完整定义（提示词+工具Schema）注入上下文。这类似于网页的“懒加载”——先显示标题，点击后再加载全文。

6.2 多级动态注入

Skill内部可以嵌套其他Skill，形成层级结构。Agent可以根据任务复杂程度，逐级注入所需的子Skill。例如：

  • 顶层：“代码审查Skill” → 注入基本规则

  • 若发现需要安全检查 → 注入“安全扫描子Skill”

  • 若发现需要性能分析 → 注入“性能分析子Skill”

这种动态注入机制，恰好弥补了MCP“全部注入”的缺点。而它之所以有效，根本原因在于AI的特点：上下文敏感。模型对上下文中的无关信息极为敏感（噪声会直接降低质量），对总长度也有限制（平方复杂度）。

Harness工程：软件工程在AI时代的重应用

模型的概率性的，输出结果的确定要如何保证？

所有依靠概率模型作为唯一约束的结果都是脆弱的。

Harness工程（编排工程）不是什么全新的东西，本质上就是软件工程在AI时代的重应用。

Harness工程关注的是如何将模型调用、工具执行、上下文构建、人工反馈等环节，组成一个稳定、可观测、可迭代的系统。

如何保证稳定可预期的结果？

核心：约束与评估/反馈环

Harness工程的核心不是“更聪明的提示词”，靠评估函数，靠约束反馈环

  • 约束：包括限制Agent的行动范围（白名单工具）、上下文长度（防止溢出）、推理步数（防止无限循环）、成本上限（单次对话Token预算）。约束让不可控的模型输出变得可控。

  • 评估/反馈环：需要有个评估函数，对AI的输出和执行结果做评估。将执行结果（成功/失败、耗时、成本、用户评价）作为反馈，输入到系统的下一轮迭代中。反馈可以是离线的（评估数据集）或在线的（用户点赞/点踩）。

本质上，harness工程，就是软件工程，而已。

总结：从Chat到Harness，始终围绕上下文

阶段 核心产物 上下文的形态 主要问题
Chat 对话 原始对话历史 无工具、无记忆
提示词工程 智能体（固定提示词+RAG） 固定系统提示词 + 检索片段 静态、无法动态调度工具
Tool Call 结构化输出 加入工具定义和调用历史 工具多了窗口爆炸
上下文工程 动态上下文管理 检索排序、历史压缩、结构化注入 仍是“全部注入”
MCP 标准化工具接口 多Server工具定义全部挤入 全部注入，窗口浪费
Skill 渐进式披露 按需动态注入模块 需要编排系统
Harness 约束与反馈环 整个上下文作为受控变量 工程复杂度高

核心观点：每一次演进，都在解决同一个问题——如何在有限的上下文窗口中，以最低的噪声、最高的信息密度，为模型提供它当前步骤真正需要的信息。模型是无状态的，所以上下文就是一切。而Harness工程，就是用软件工程的约束与反馈环，把上下文的构建、注入、评估、优化，变成可重复、可规模化的流程。

从使用者来看: 除了提示词, 没有新东西

清除恐惧

基模的技术日新月异, 但是对于使用者来说, 不关心.

应用方向, 新词概念层出不穷, 但是没有离开提示词的, 不要被概念击溃.

模型是无状态的

所谓的viber coding, 就是说话让AI编程;

所谓的spec coding, 就是写文档, 记笔记

所谓的function call, tool call, mcp, skill, 就是AI说话, agent调用工具.

所谓的Harness, 就是约束检查, 测试反馈, 流程编排.

各种词的噪声从我们脑子里去除后, 只剩下提示词, 上下文.

只剩下怎么管理你的上下文.

怎么实现AGI, 答案很简单, 代码. 所以大家都疯了一样往基模和编码方向发力.

怎么管理上下文, 答案很简单, 用软件工程.

用确定性的约束, 用短 周期的反馈环让AI自迭代, 用测试驱动开发. 这就是Harness工程的本质.

约束是什么, cleancode, lint, format, check; 是圈复杂度, 扇入扇出, 高内聚低耦合;是开发者测试, 单元测试

是权限, 白名单, 异常处理, fall back;

不过都是提示词. 不过都是旧东西, 不要恐惧.

基础模型

使用模型需要有一些基本的概率，稍微看一下

模型

  1. 参数量（如7B、70B）：参数越多，模型通常越“聪明”，但推理更慢、更贵。
  2. 混合专家模型（MoE）与激活参数：MoE模型的总参数量很大（例如 MoE 8×7B=56B），但每次推理只激活其中一小部分专家（如13B）。这意味着你支付的“算力成本”对应激活参数，而非总参数。
  3. 量化（FP16/INT8/INT4）：量化是把高精度参数压缩为低精度整数，以减小模型体积、加快推理。FP16是常见默认精度；INT8/INT4体积更小（7B模型可缩至3.5GB），但可能轻微损失效果。(GLM-4.7-FP8)
  4. 上下文窗口（Context Window）：模型能一次处理的最大Token数（如128K、200K、1M）。超过窗口，早期信息会被截断。使用时注意控制输入总长度，尤其是多轮对话或RAG场景。
  5. 缓存命中（Prompt Caching）：如果多个请求的输入前缀（如系统提示词、历史对话）完全相同，API会复用之前计算的中间结果（KV缓存），大幅降低延迟和成本（节省50%~90%）。设计应用时，尽量让系统提示词固定、历史消息结构一致，以提高缓存命中率。

API

  1. OpenAI Compatible：事实标准。请求格式为 POST /v1/chat/completions，头部 Authorization: Bearer <API_KEY>，Body包含 model、messages、temperature 等。绝大多数开源模型和商业API都兼容此格式。
  2. Anthropic风格：Claude系列使用的独立格式，端点与字段不同（例如用 text 而非 messages）。如需使用Claude，按Anthropic文档调用。
  3. temperature：控制输出的随机性，范围0~2。0：几乎确定性输出（适合代码、事实问答）；1：平衡；>1：更多样（适合创意写作）。建议从0.7开始调试。
  4. max_tokens：限制模型生成的最大Token数（不含输入）。设置合理上限可避免无限输出和过高账单。

输入输出与缓存：

  1. 输入：messages数组，输出：choices[0].message.content
  2. Prompt Caching：当多个请求的输入前缀完全一致时，API可以复用之前计算的KV缓存，大幅降低延时和成本（节省50%~90%）。这是信息论中消除重复计算的重要优化。

使用agent客户端

  1. skill管理
    npx skills add https://github.com/anthropics/skills --skill skill-creator
  2. mcp管理
    • mcp-registry add everything npx -y @modelcontextprotocol/server-everything
    • 用户可以减少使用，可以转成skill mcp-to-skill
  3. API 管理
    • 普通人咬定一个agent就够了，比如opencode，不用操心这个
    • 公司可以用new-api自建代理，把公司提供的模型聚合起来，自动fallback，这样多个agent可以只配置一次

提高与AI交流的信息密度

怎么样让AI更容易更好地理解我们工作，怎样提高与AI交流的信息密度呢？

我们从AI的特点出发来分析, 容易得出

第一, 结构化的数据，Json markdown, XML,HTML，Python bash这些是AI比较喜欢的。

第二, 命令行环境，Linux/unix 环境, 有句话叫, sh是最好的agent

第三文本为核心。包括现在很多模型宣传多模态，很多AI对于图片的理解还是调用OCR工具，或者先调用图片理解模型，把图片转成文字，再喂给AI去处理，核心还是文本。

基于这3个特点，我们就能很容易理解，为什么现在大多数的AI公司都转向了CLI编程工具的开发，转向了以命令行为主的工作流编排。一个显而易见的结论是，抛弃Windows，使用linux，使用mac; 抛弃word，使用markdown，抛弃PPT使用HTML。

Markdown和HTML是显然的. AI输出就是MD格式，所有的代码、数据脚本、安装指导文件README全是markdown。

至于HTML，让AI做网页非常轻而易举，AI天生就是干这个的，外国的网站文化比较流行，所以产品演示都是一句话生成一个网页，实现一下网页游戏。网页是一个默认的运行时，而且它的兼容性天然就比较好。

当然我们还发现，不管是AI客户端还是AI CLI程序都离不开以nodejs和electron框架为基础的天然支持跨平台的前端技术栈. 大家安装时都是nodejs, npm install. 目前看, 以Linux为主的三端合一的趋势很明显. 无论是claudecode opencode 还是vscode Cherry-studio等.

接下来是抛弃windows. 不论是claudecode opencode，乃至现在的openclaw，claudecowork，都是建立在以Linux发行版/MacOS等操作系统上, 从来没有第一时间支持过Windows。我们当然可以说现在已经有一些桌面客户端助手了，但不论是开发进度还是效果，远远不如Linux环境命令行环境下的CLI工具。在智能化的浪潮下，Windows天生就比能力落后一截。这是一个空白，当然也是一个机遇，但是如果没有想要去抓住这个机遇的话，我们没必要去做这个事情，没必要走更长的路，折腾半天，最后获得比别人差的效果。

总结

稍微总结一下我们的观点： 建立以AI为核心，而不是以人为核心的工作流。

AI的本质是数据加算法的概率预测。高质量的信息+算法模型是工作流编排的核心。

信息是向量, 需要清洗, 编排, 动态载入.

AI的特点是结构化，文本化，命令行，所以我们要建立以结构化, 文本化，命令行为核心的AI工作流。

上下文唯一决定了AI的效果, 上下文编排是业界正在努力解决的问题.

上下文是一切工程的核心.

上下文编排是Agent关心的事情, 我们关心的是, 如何对结果进行约束和评价, 建立反馈飞轮.

题外话

AI时代需要关注的技术栈, 经常在各个环节出没.

  • 以nodejs+electron/Tauri 为代表的天然跨平台的能力, AI开发最爱.

  • python, sh为代表的命令行执行能力, shell is the best agent.

  • rust建设的基础设施, 组成了大部分agent的原子能力

    • ast-grep, fd, rg, bun, uv, Tauri等等

  • 图怎么读, 怎么写

    • SVG

    • digram

    • mermaid

Ref:

  1. 万字干货！Harness Engineering如何工程化落地？

  2. Qoder 工程实践：Harness Engineering 指南