置顶

勘误反馈
如果对本博客文章有任何问题(如探讨、建议、文字或逻辑错误等)都可以给我发邮件：

  • 邮件标题：[wds博客问题反馈] - 希望在XXX文章增加一些细节的补充
  • 邮件地址：8851970@qq.com

Read More

专项话题►回忆AI时代-从图灵机到人工智能

Harness


📚 文章 ( 📝 字数： 1.4k ⏱ 阅读时间： 5 分钟 )

系列文章见: 《回忆AI时代-从图灵机到人工智能》

什么是Harness

2026年2月，OpenAI工程师Ryan Lopopolo发表了一篇颇具影响力的文章《Harness Engineering: Leveraging Codex in an Agent-First World》。
文中披露了一组令人印象深刻的数据,一个小团队仅用了5个月，借助Codex自动完成了约100万行代码、创建了1500个PR，整个过程中几乎没有人工编写任何代码。这并非实验室里的Demo，而是一套已经拥有内部日活用户的真实生产系统。OpenAI将这种全新的AI开发模式称为Harness Engineering。

Harness的本意

Harness原本是一个英语单词，意思是马具、挽具。一匹马再强壮，如果没有马鞍、缰绳和车架，就无法稳定地拉动车辆，更无法按照人的意图完成复杂任务。

如果把AI大模型比作一匹拥有巨大潜力的骏马，那么Harness就相当于驾驭它的一整套装备——不仅包括缰绳和马鞍，还包括马车、驾驶规则以及控制系统。它负责让模型的能力真正转化为稳定、可靠、可持续的生产力。

AI编程中的Harness

在AI编程领域，Harness并不是模型本身，而是围绕模型构建的一整套工程化支撑系统。

它包含了模型之外所有用于约束、增强、管理和协同模型工作的基础设施，使原本只能进行单次推理的大模型，能够持续、稳定地完成复杂的软件开发任务。可以把它理解为：

1
Harness = 模型之外的一切工程能力。

这些能力通常包括：

  • 为模型提供上下文（Context）和提示词（Prompt）；
  • 调用各种工具（Tools）和外部 API；
  • 管理记忆（Memory）和长期状态；
  • 自动执行、测试、调试代码；
  • 与 Git、PR、CI/CD 等开发流程集成；
  • 控制任务规划、权限、安全和错误恢复；
  • 协调多个 Agent 协同完成复杂任务。

因此，真正决定AI能否参与大型软件工程的，不仅仅是模型本身，更重要的是这套围绕模型构建的 Harness。可以说，模型负责“思考”，而 Harness 负责“让思考真正落地执行”。随着AI Agent的快速发展，业界越来越认同一个观点Agent = LLM + Harness其中，LLM提供智能，而Harness 提供工程能力,二者结合，才能让AI从一个“会回答问题的大模型”，成长为一个真正能够独立完成工作的智能体（Agent）。

Harness 要解决什么问题

虽然今天的大模型能力已经非常强，但仍然存在一些天然缺陷，例如：

  • 输出具有概率性，同一个问题可能得到不同答案；
  • 存在幻觉（Hallucination），会生成看似合理但实际错误的内容；
  • 对隐含约束理解不稳定，容易遗漏用户要求；
  • 上下文窗口有限，长任务容易遗忘前面的信息；
  • 多步骤任务容易跑偏，缺乏长期规划能力；
  • 无法主动验证自己的输出是否正确。

Harness的作用，就是利用确定性的工程代码来弥补这些不足。

模型负责自己最擅长的事情——理解、推理和生成；而约束、校验、调度、恢复等工作，则交给 Harness 完成。

Harness的典型组成

    1. 上下文管理（Context）
    1. 执行能力（Tools）
    1. 任务编排（Orchestration）
    1. 反馈机制（Feedback）
    1. 架构护栏（Guardrails）
    1. 其他基础设施

1. 上下文管理（Context）

帮助 AI 在正确的背景下工作。典型能力包括：

  • 项目规则文件（例如 AGENTS.md）
  • RAG（检索增强生成）
  • 长期记忆（Memory）
  • 上下文压缩
  • 历史对话管理
  • 技术栈、编码规范自动加载

目标是让模型始终拥有完成当前任务所需的信息，同时避免上下文过长导致注意力稀释。

2. 执行能力（Tools）

赋予 AI 操作真实世界的能力。例如：

  • 文件读写
  • Shell 命令
  • Git 操作
  • 浏览器访问
  • 数据库查询
  • MCP（Model Context Protocol）
  • Agent Skills
  • 第三方 API

有了工具之后，AI 不再只是回答问题，而是真正能够完成实际任务。

3. 任务编排（Orchestration）

负责组织复杂任务的执行流程。例如：

  • 将大型任务拆分为多个子任务
  • 控制执行顺序
  • 并行执行多个 Agent
  • 管理任务状态
  • 保存执行进度
  • 防止上下文溢出

它相当于整个 Agent 系统的”项目经理”。

4. 反馈机制（Feedback）

帮助 AI 自我检查和持续改进。常见方式包括：

  • Linter
  • 自动化测试
  • 单元测试
  • 自我验证脚本
  • 多 Agent 交叉评审
  • 人工审核节点

形成：生成 → 检查 → 修复 → 再检查这样的闭环，而不是一次生成后直接结束。

5. 架构护栏（Guardrails）

用于保证长期迭代过程中代码质量不会持续下降。例如：

  • Linter 规则
  • pre-commit Hooks
  • CI/CD 检查
  • 安全扫描
  • 自动代码修复
  • 架构规范校验

它们能够保证AI即使连续工作数月，也不会逐渐偏离既定的软件架构。

  1. 其他基础设施

成熟的 Harness 往往还包含大量通用能力，例如：

  • 权限控制（Permission）
  • Hook 钩子系统
  • 错误恢复（Recovery）
  • 状态持久化（State Persistence）
  • 可观测性（Logging & Tracing）
  • 人机协同（Human-in-the-loop）

这些模块共同构成了一套完整的AI工程运行环境。

专项话题►回忆AI时代-从图灵机到人工智能

AI的寒冬期


📚 文章 ( 📝 字数： 853 ⏱ 阅读时间： 2 分钟 )

系列文章见: 《回忆AI时代-从图灵机到人工智能》

1956年，达特茅斯会议正式提出 Artificial Intelligence（人工智能）概念，此后AI迎来第一轮高速发展，相继诞生搜索算法、国际象棋程序、数学定理证明、自然语言理解、感知机等标志性成果。彼时大批科学家信心高涨，乐观预言二十年之内机器将胜任人类的全部工作。

恰逢美苏冷战阶段，各国急需大批量自动翻译俄文科技文献，行业提出了无需人工介入、实现多国语言全自动互译的宏大目标。全社会对人工智能抱有极高期待，催生了严重的行业泡沫。盲目乐观带来的技术愿景远远超出了当时硬件与算法的实际能力，理想迅速撞上现实瓶颈，人工智能接连迎来两次寒冬：

  • 第一个寒冬期（1974-1980）
  • 第二个寒冬期（1987-1993）

第一个寒冬期

进度寒冬期共有五个原因：

  • 1. 计算机太慢：1970 年大型计算机几万倍以上的算力，很多算法理论上可以运行，譬如搜索树，但因为计算慢搜索空间爆炸，导致程序越来越慢。
  • 2. 机器学习能力几乎没有：在那个时间段，主要还处于规则时代，如果规则不全，程序就不知道下一步怎么做。
  • 3. 感知机被证明能力有限：不能解决 XOR 问题。
  • 4. 政府削减经费：英国发布了著名的 Lighthill Report报告指出，AI 的成果远没有宣传那么好。随后英国政府大幅减少AI研究经费，美国国防部门也逐渐减少投入。
  • 5. 过度宣传：自动翻译、自动推理和自动理解世界，但结果都没有实现。

第二次 AI 寒冬

专家系统（Expert System）突然火起来，譬如医疗、金融、保险、制造都在大量使用，很多公司认为AI时代已经到来，但最终又是失败。主要原因：

  • 1. 知识获取困难：专家系统需要自己写规则，如果一个医生有10万条规则，程序员就需要写10万条规则，同时医生很多判断依赖长期经验，所以导致这里知识获取困难。
  • 2. 维护成本高：新增一条规则，可能会影响其它规则，导致规则越来越复杂
  • 3. 不能学习：专家系统不会自己学习，一条规则录入后，后续变化无法及时更新。
  • 4. 专用AI硬件市场崩溃：当时很多企业购买昂贵的Lisp Machine来运行AI软件。后来普通工作站尤其是基于Unix的工作站和PC越来越便宜，性能迅速提升，导致昂贵的AI专用硬件失去竞争力，相关厂商大量倒闭。
  • 5. 商业泡沫：大量公司名字里只要带AI就能融资,后来效果不好投资全部撤离。
  • 日本第五代计算机计划失败:1982年，日本第五代计算机系统项目投入巨额资金，希望开发基于逻辑推理的新一代智能计算机,但最终目标没有实现，世界开始重新怀疑AI。
专项话题►回忆AI时代-从图灵机到人工智能

为什么大模型最小单位Token？它是怎么计算的？

系列文章见: 《回忆AI时代-从图灵机到人工智能》

什么是Token

在人工智能领域Token被翻译为词元,它是AI模型理解和处理文本的最小基础单位。 模型不能直接阅读人类的文字，它只能理解数字，因此输入给模型的提示词和模型输出的文字，都会先被拆解成一个个 Token，然后再转换成数字进行运算。

大模型如何计算Token

我们通过一个案例来介绍大模型Token的统计方式，一共分为三步：

  • 用户输入问题
  • 模型理解整个问题
  • 开始生成答案

1.用户输入问题

譬如，你问大模型：

1
“什么是机器学习？”

对于模型来说，第一步不是理解文字而是通过Tokenizer（分词器）先把它转换成Token ID,譬如：

文本 Token Token ID
什么 什么 1523
是 是 87
机器学习 机器学习 9361
？ ？ 34

按照以上表格对应关系，模型会收到 “[1523, 87, 9361, 34]”，模型会再把Token ID转成向量，如下：

Token ID 向量
1523 [0.12, -0.55, 1.03, …]
87 [-0.31, 0.98, …]
9361 [0.42, -0.67, …]

这也就是说模型不能直接阅读人类的文字，它只能理解数字。到目前已经完整了文字与计算机理解的数字转换。

Read More

专项话题►回忆AI时代-从图灵机到人工智能

1980年的专家系统

系列文章见: 《回忆AI时代-从图灵机到人工智能》

什么是专家系统

1980年，被称为专家系统（Expert Systems）时代，也是第一波AI商业化浪潮，这一时期AI的核心思想属于符号主义（Symbolic AI）或规则驱动 AI（Rule-based AI）。1970年代末研究人员发现与其让计算机像人一样学习，不如先把专家的知识直接写进去，譬如：

  • 医生如何诊断疾病
  • 地质学家如何寻找矿藏
  • 工程师如何维修设备

如果把这些经验写成IF条件THEN结论，计算机就能够像专家一样推理。

1
2
3
4
IF
    发烧 AND 咳嗽 AND 白细胞高
THEN
    可能是细菌感染

专家系统的组成,通常分为四个部分：

  • 知识库（Knowledge Base）
  • 推理机（Inference Engine）
  • 事实库（Working Memory）
  • 用户界面(User Interface)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
             用户
              │
       ┌─────────────┐
       │    用户界面  │
       └─────────────┘
              │
       ┌─────────────┐
       │     推理机   │
       └─────────────┘
        │          │
        │          │
┌────────────┐  ┌────────────┐
│   知识库    │  │ 事实库      │
│   Rules    │  │ 当前数据    │
└────────────┘  └────────────┘

Read More

专项话题►回忆AI时代-从图灵机到人工智能

1966年的人机对话程序ELIZA


📚 文章 ( 📝 字数： 305 ⏱ 阅读时间： 1 分钟 )

系列文章见: 《回忆AI时代-从图灵机到人工智能》

ELIZA是规则驱动的对话程序，由Joseph Weizenbaum在1964–1966年开发，ELIZA是人工智能发展史上的一个重要里程碑是最早展示人机自然语言对话可能性的程序之一，它代表了符号主义（规则驱动 AI）的早期成果，虽然它没有真正的语言理解能力，但证明了人机自然语言对话是可行的，也启发了后来的聊天机器人研究。

ELIZA主要的工作原理：

  • 关键词匹配（Keyword Matching）
  • 模式匹配（Pattern Matching）
  • 模板回复（Template Response）

用一个Python来解释它的工作原理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import re

rules = [
    (r"I feel (.*)",
     "Why do you feel {}?"),

    (r"I need (.*)",
     "Why do you need {}?"),

    (r"My (.*)",
     "Tell me more about your {}."),

    (r".*",
     "Please go on.")
]

while True:
    text = input("You: ")

    if text == "quit":
        break

    for pattern, reply in rules:
        m = re.match(pattern, text, re.I)
        if m:
            if m.groups():
                print("ELIZA:", reply.format(m.group(1)))
            else:
                print("ELIZA:", reply)
            break

运行效果：

1
2
3
4
5
6
7
8
You: I feel tired
ELIZA: Why do you feel tired?

You: My father is strict
ELIZA: Tell me more about your father is strict.

You: Hello
ELIZA: Please go on.
专项话题►回忆AI时代-从图灵机到人工智能

如何与大模型交互-Prompt


📚 文章 ( 📝 字数： 651 ⏱ 阅读时间： 2 分钟 )

系列文章见: 《回忆AI时代-从图灵机到人工智能》

Prompt的来源

大模型目前主要的交互方式是Prompt（提示词，下文统称”提示词“），因为大模型本质上是一个根据已有内容继续预测下一个Token的模型，假设模型内部其实一直在做这样的事情：

1
2
3
今天的天气很好，
↓↓↓
预测下一个 Token

如果你什么都不给它，它不知道应该生成什么。所以你必须给它一个开头如”请介绍一下机器学习”，告知大模型朝哪个方向继续生成，这就是”提示词“这个词的来源。

如何与大模型交互

为什么不是问题

那大模型什么输入的不叫问题？ 来看一下问题与提示词差别：

Question（问题） Prompt（提示）
一定是疑问句 不一定是问题
主要用于提问 可以是任何输入
例如：”什么是 AI？” 可以是一篇文章、一段代码、一张表格、一段角色设定等

我们聊天也叫Prompt、让模型生成一张图片也是prompt。

如何写好一个提示词

在日常应用大模型过程中写好一个提示词至关重要，它能帮你解决问题的同时还可以帮您节约Token的输出量，而Token量的节约也就是为你节约成本，因为目前大模型主要的计费方式就是Toekn。这里推荐一个实用的框架：

项目 含义 示例
C（Context） 背景 我正在学习大模型
O（Objective） 目标 帮我理解 Token
S（Style） 风格 通俗易懂
T（Tone） 语气 像老师讲课
A（Audience） 受众 零基础程序员
R（Response） 输出格式 Markdown，包含流程图和示例

提示词示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
角色：
你是一位人工智能领域的大学教授。

任务：
请讲解什么是 Transformer。

背景：
我是一个刚学习深度学习的人，
已经掌握Python和神经网络，
但没有学习过Attention。

要求：
1. 从为什么需要Transformer开始
2. 再讲Self-Attention
3. 最后讲Encoder和Decoder
4. 使用生活中的例子
5. 尽量不要使用复杂数学公式

输出：
使用Markdown，
包含流程图，
最后给出一个PyTorch示例。

一个好的Prompt并不是越长越好，而是目标明确、上下文充分、要求具体、输出格式清晰。当你把模型当作一位专业人士，清楚地说明”你是谁、要做什么、为什么做、希望如何输出”，回答质量通常会明显提升!