从 Prompt Engineer 到 Harness Engineer：AI 工程能力的三次跃迁

引言

2023 年，Prompt Engineer 成为科技圈最热门的新职业。人们相信，掌握与大语言模型"对话"的技巧，就能驾驭 AI 的全部能力。两年后的今天，这个认知已经发生了根本性转变。

从写好一段提示词，到构建完整的上下文环境，再到设计 Agent 运行的整个"线束"（Harness）——AI 工程能力正在经历三次深刻的范式跃迁。每一次跃迁不是对前者的否定，而是在更高维度上的包含与超越。

本文将梳理这条演进路径，帮助你理解：为什么 Prompt Engineering 不够用？Context Engineering 解决了什么问题？Harness Engineering 又意味着什么？

第一次跃迁：Prompt Engineering —— 与 AI 对话的艺术

什么是 Prompt Engineering？

Prompt Engineering 的核心假设是：只要给 AI 正确的指令，它就能给出正确的结果。工程师的工作重心在于设计、优化和迭代提示词（Prompt），以引导大语言模型产生期望的输出。

核心技术手段

1. 指令设计

你是一位资深 Python 开发者。请根据以下需求编写一个函数：
- 输入：一个整数列表
- 输出：列表中所有偶数的平方和
- 要求：使用列表推导式，并添加类型注解

关键要素：角色定义、输入输出规范、约束条件。

2. Few-Shot 示例

请按照以下格式翻译：

中文: 今天天气不错
英文: The weather is nice today

中文: 我在学习 AI
英文: I'm learning AI

中文: [用户输入]
英文:

通过示例"教会"模型期望的输出格式和风格。

3. Chain-of-Thought（思维链）

请一步步思考以下问题：
一个商店有 23 个苹果，卖了 15 个，又进货了 8 个。现在有多少个苹果？

让模型展示推理过程，提升复杂任务的准确率。

4. 结构化 Prompt

# 角色
你是一个代码审查专家。

# 任务
审查以下 PR 的代码变更。

# 审查维度
1. 安全性：是否存在注入漏洞
2. 性能：是否有明显的性能问题
3. 可读性：命名和结构是否清晰

# 输出格式
以 Markdown 表格形式输出审查结果。

Prompt Engineering 的局限

Prompt Engineering 面临三个根本性限制：

局限 1：信息密度瓶颈

无论提示词写得多好，它能携带的信息量是有限的。当你需要让 AI 理解一个拥有 10 万行代码的项目时，一段提示词远远不够。

局限 2：静态知识陷阱

提示词在发出后就固定了。它无法根据 AI 在执行过程中的发现动态调整，无法补充新发现的关键信息。

局限 3：缺乏执行环境

提示词只能告诉 AI "做什么"，但无法提供"在哪里做"、"用什么工具做"的基础设施。AI 的输出仍然只是文本，无法直接作用于真实世界。

一句话总结：Prompt Engineering 解决的是"如何向 AI 提出好问题"，但没有解决"如何让 AI 拥有解决问题所需的一切"。

第二次跃迁：Context Engineering —— 为 AI 构建认知环境

为什么需要 Context Engineering？

2025 年，Andrej Karpathy 提出："Context Engineering 是新的 Prompt Engineering。" 这一判断精准地捕捉到了范式的转变。

当 AI Agent 需要在真实世界中工作时，它需要的不仅仅是一个好指令——它需要完整的上下文环境来做出正确的决策。

Context Engineering 的核心思想

Context Engineering 的核心假设是：AI 的输出质量，取决于它所能感知的上下文质量。工程师的工作重心从"写好提示词"转向"构建完整的上下文管道"。

关键技术维度

1. 上下文收集与注入

# 不是静态的提示词，而是动态构建的上下文
def build_context(task, codebase):
    context = []

    # 项目结构
    context.append(get_project_structure())

    # 相关代码文件
    relevant_files = semantic_search(task, codebase)
    for file in relevant_files:
        context.append(read_file(file))

    # 当前 Git 状态
    context.append(git_diff())

    # 依赖关系
    context.append(analyze_dependencies())

    # 编码规范
    context.append(read_file(".editorconfig"))
    context.append(read_file("CONTRIBUTING.md"))

    return assemble_context(context)

2. 上下文窗口管理

现代 LLM 的上下文窗口从 4K 扩展到 128K、200K 甚至 1M tokens。但"能放进去"不等于"用得好"。Context Engineering 需要解决：

上下文窗口（200K tokens）
├── 系统指令          ~2K tokens
├── 项目上下文        ~20K tokens
│   ├── 项目结构
│   ├── 编码规范
│   └── 相关代码
├── 对话历史          ~30K tokens
├── 工具调用结果       ~50K tokens
│   ├── 搜索结果
│   ├── 文件内容
│   └── 命令输出
└── 预留空间          ~98K tokens
    （给模型输出和后续交互）

3. RAG（检索增强生成）

用户查询: "这个项目的认证逻辑在哪里？"
        ↓
[1] 向量搜索: 在代码库中找到相关片段
        ↓
[2] 排序: 按相关度排序搜索结果
        ↓
[3] 截断: 选择最相关的 K 个片段
        ↓
[4] 注入: 将代码片段注入上下文
        ↓
[5] LLM 推理: 基于上下文回答问题

4. 动态上下文更新

Agent 执行过程中的上下文演化：

T0: [系统指令, 项目结构, 用户需求]
     ↓ Agent: "我需要查看 auth.ts"
T1: [系统指令, 项目结构, 用户需求, auth.ts 内容]
     ↓ Agent: "我发现引用了 jwt.ts，需要查看"
T2: [系统指令, 项目结构, 用户需求, auth.ts, jwt.ts, 压缩的项目结构]
     ↓ Agent: "现在我可以修改了"
T3: [系统指令, 用户需求, auth.ts(修改版), jwt.ts, 变更摘要]

注意上下文窗口中内容的动态变化：旧的、不那么相关的信息被压缩或移除，新的关键信息被注入。

5. CLAUDE.md 模式

Claude Code 引入的 CLAUDE.md 文件是 Context Engineering 的典型实践：

# CLAUDE.md - 项目上下文文件

## 项目概述
这是一个基于 Next.js 14 的电商网站，使用 App Router 和 Server Components。

## 技术栈
- Framework: Next.js 14 (App Router)
- Database: PostgreSQL + Prisma ORM
- Auth: NextAuth.js v5
- Styling: Tailwind CSS + shadcn/ui

## 编码规范
- 使用函数式组件，禁止 class 组件
- 使用 TypeScript strict 模式
- API 路由必须包含错误处理和输入验证
- 测试使用 Vitest + Testing Library

## 项目结构
- src/app/ - 页面路由
- src/components/ - React 组件
- src/lib/ - 工具函数
- src/services/ - 业务逻辑层

这个文件在每次对话开始时自动注入上下文，让 AI 立刻理解项目全貌。

Context Engineering 的局限

Context Engineering 极大地提升了 AI 的理解和推理能力，但它仍然有边界：

局限 1：上下文终究是信息，不是行动力

即使 AI 看到了所有代码，理解了所有上下文，它仍然只是在"看"。它不能直接运行代码、不能部署、不能操作数据库——除非有工具。

局限 2：线性流程的天花板

上下文管理本质上是一条线性的信息流：收集 → 注入 → 推理 → 输出。但真实的工程任务往往是非线性的：需要探索、试错、回溯、并行处理。

局限 3：单一 Agent 的瓶颈

无论上下文多么丰富，单一 Agent 的注意力有限。它无法同时扮演架构师、开发者和测试工程师的角色——就像一个人无法同时身兼数职一样。

一句话总结：Context Engineering 解决了"让 AI 看到全景"，但没有解决"让 AI 像团队一样行动"。

第三次跃迁：Harness Engineering —— 构建 Agent 运行的线束

什么是 Harness Engineering？

Harness 一词来源于软件工程中的"测试线束"（Test Harness）——为被测试代码搭建的完整运行环境，包括驱动程序、桩模块、测试数据、监控工具等。

Harness Engineering 将这个概念扩展到 AI Agent 领域：为 Agent 搭建完整的"运行线束"——包括工具集、权限边界、协作机制、安全护栏、监控系统和执行流程。

如果说 Prompt Engineering 是在写剧本，Context Engineering 是在搭建舞台，那么 Harness Engineering 就是在建造整个剧院——包括舞台、灯光、音响、演员调度系统和安全通道。

Harness Engineering 的核心假设

AI Agent 的能力上限，不取决于模型本身，而取决于它运行的线束架构。

一个强大的模型配上简陋的线束，表现不如一个普通模型配上精心设计的线束。

Harness 的核心构成

┌─────────────────────────────────────────────────┐
│                  Agent Harness                    │
│                                                   │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐    │
│  │  Prompt    │  │  Context  │  │  Tools    │    │
│  │  Layer     │  │  Layer    │  │  Layer    │    │
│  └───────────┘  └───────────┘  └───────────┘    │
│                                                   │
│  ┌─────────────────────────────────────────────┐ │
│  │           Orchestration Layer                │ │
│  │  ┌────────┐ ┌────────┐ ┌────────────────┐  │ │
│  │  │ Router │ │ Guard  │ │  State Manager │  │ │
│  │  └────────┘ └────────┘ └────────────────┘  │ │
│  └─────────────────────────────────────────────┘ │
│                                                   │
│  ┌─────────────────────────────────────────────┐ │
│  │           Multi-Agent Layer                  │ │
│  │  ┌────────┐ ┌────────┐ ┌────────────────┐  │ │
│  │  │Explorer│ │ Planner│ │   Executor     │  │ │
│  │  └────────┘ └────────┘ └────────────────┘  │ │
│  │  ┌────────┐ ┌────────┐                     │ │
│  │  │Reviewer│ │Verifier│                     │ │
│  │  └────────┘ └────────┘                     │ │
│  └─────────────────────────────────────────────┘ │
│                                                   │
│  ┌─────────────────────────────────────────────┐ │
│  │           Safety & Observability Layer       │ │
│  │  ┌────────┐ ┌────────┐ ┌────────────────┐  │ │
│  │  │Sandbox │ │ Audit  │ │   Telemetry    │  │ │
│  │  └────────┘ └────────┘ └────────────────┘  │ │
│  └─────────────────────────────────────────────┘ │
│                                                   │
└─────────────────────────────────────────────────┘

第一层：Prompt Layer（提示层）

这是 Harness 的最内层，直接继承 Prompt Engineering 的全部成果。但 Harness 视角下的 Prompt 有一个关键不同：它不是静态的，而是参数化的。

# 传统 Prompt Engineering
prompt = "你是一个代码审查专家，请审查以下代码..."

# Harness 中的参数化 Prompt
class CodeReviewPrompt:
    def __init__(self, context):
        self.language = context.project_language
        self.standards = context.coding_standards
        self.focus_areas = context.user_preferences.get("review_focus", ["security"])

    def render(self, code_diff):
        return f"""
        你是一个 {self.language} 代码审查专家。

        项目编码规范：
        {self.standards}

        重点关注：
        {', '.join(self.focus_areas)}

        待审查代码变更：
        {code_diff}

        请输出结构化审查报告。
        """

第二层：Context Layer（上下文层）

继承 Context Engineering 的成果，但在 Harness 中上下文管理变成了系统行为而非人工操作。

class ContextManager:
    """Harness 中的自动化上下文管理"""

    def __init__(self, codebase):
        self.codebase = codebase
        self.index = build_vector_index(codebase)
        self.window_budget = 200_000  # tokens

    def prepare_for_task(self, task):
        """根据任务自动准备最优上下文"""
        budget = self.window_budget
        context_parts = []

        # 1. 系统指令（必需）
        system_prompt = self._render_system_prompt()
        budget -= count_tokens(system_prompt)
        context_parts.append(system_prompt)

        # 2. 项目元信息
        project_context = self._get_project_context()
        budget -= count_tokens(project_context)
        context_parts.append(project_context)

        # 3. 任务相关的动态检索
        relevant_code = self.index.search(task.description, top_k=10)
        for code in relevant_code:
            if count_tokens(code) < budget:
                context_parts.append(code)
                budget -= count_tokens(code)

        # 4. 保留足够输出空间
        return assemble(context_parts, output_budget=budget)

第三层：Tools Layer（工具层）

这是 Harness 开始超越前两个范式的关键层。工具赋予 Agent 行动力。

Agent 可用的工具集：

文件操作
├── Read:   读取文件
├── Edit:   精确替换文件内容
├── Write:  创建新文件
└── Glob:   按模式搜索文件名

搜索分析
├── Grep:   按正则表达式搜索文件内容
└── Task:   启动子 Agent 执行专项任务

终端操作
└── Bash:   执行 Shell 命令
    ├── git 操作
    ├── npm/pip 包管理
    ├── 测试运行
    └── 构建部署

交互
├── AskUserQuestion: 向用户提问
└── TodoWrite:       管理任务进度

工具层的设计核心是权限控制：

# 不同 Agent 配备不同的工具集
AGENT_TOOLS = {
    "Explorer": ["Read", "Glob", "Grep"],           # 只读
    "Planner":  ["Read", "Glob", "Grep"],            # 只读
    "Coder":    ["Read", "Edit", "Write", "Bash"],   # 读写
    "Reviewer": ["Read", "Glob", "Grep"],            # 只读
}

第四层：Orchestration Layer（编排层）

编排层是 Harness 的"大脑"，负责协调 Agent 的行为：

1. 路由（Router）

用户请求: "重构认证模块"

Router 分析:
├── 任务类型: 重构
├── 复杂度: 高（涉及多文件）
├── 需要规划: 是
└── 需要验证: 是

调度计划:
[1] Explore Agent → 探索现有认证代码
[2] Plan Agent → 设计重构方案
[3] 用户确认 → 审批方案
[4] 主 Agent → 执行重构
[5] Code-Reviewer Agent → 审查质量

2. 安全护栏（Guard）

class SafetyGuard:
    """Harness 安全护栏"""

    BLOCKED_COMMANDS = [
        "rm -rf /",
        "DROP TABLE",
        "curl | sh",
    ]

    def check_bash_command(self, command):
        """检查命令安全性"""
        for blocked in self.BLOCKED_COMMANDS:
            if blocked in command:
                return Blocked(f"危险命令被拦截: {blocked}")

        if self.modifies_critical_files(command):
            return ConfirmationRequired(
                "此命令将修改关键文件，需要用户确认"
            )

        return Allowed(command)

    def check_file_write(self, path, content):
        """检查文件写入安全性"""
        if contains_secrets(content):
            return Blocked("检测到敏感信息（API Key/密码）")

        if is_binary_file(path):
            return Blocked("不允许写入二进制文件")

        return Allowed()

3. 状态管理（State Manager）

class StateManager:
    """跨 Agent 的共享状态管理"""

    def __init__(self):
        self.todos = []          # 任务列表
        self.completed = []      # 已完成任务
        self.artifacts = {}      # 中间产物
        self.decisions = []      # 决策记录

    def sync(self, agent_result):
        """Agent 完成后同步状态"""
        self.completed.append(agent_result.task)
        self.artifacts[agent_result.task] = agent_result.output

        # 通知后续 Agent
        for waiting_agent in self.get_waiting_agents():
            waiting_agent.notify(agent_result)

第五层：Multi-Agent Layer（多 Agent 层）

这是 Harness 真正展现威力的层次。一个精心设计的 Harness 会部署多个专业化 Agent，让它们像团队一样协作。

多 Agent 协作流程示例：添加新功能

                    用户需求
                       │
                       ▼
                ┌─────────────┐
                │   Router    │ 分析任务，制定计划
                └──────┬──────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ Explorer │ │ Explorer │ │ Explorer │  并行探索
   │ (组件)   │ │ (API)    │ │ (测试)   │
   └────┬─────┘ └────┬─────┘ └────┬─────┘
        │             │             │
        └─────────────┼─────────────┘
                      ▼
               ┌─────────────┐
               │   Planner   │ 设计实现方案
               └──────┬──────┘
                      │
                      ▼
               ┌─────────────┐
               │    用户     │ 审批方案
               └──────┬──────┘
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │  Coder   │ │  Coder   │ │  Bash    │  并行执行
   │ (前端)   │ │ (后端)   │ │ (安装)   │
   └────┬─────┘ └────┬─────┘ └────┬─────┘
        │             │             │
        └─────────────┼─────────────┘
                      ▼
               ┌─────────────┐
               │  Reviewer   │ 代码审查
               └──────┬──────┘
                      │
                      ▼
               ┌─────────────┐
               │  Verifier   │ 最终验证
               └──────┬──────┘
                      │
                      ▼
                   完成交付

第六层：Safety & Observability Layer（安全与可观测层）

可观测性三支柱：

1. 日志（Logging）
   └── 每个 Agent 的每一步操作都有记录
       ├── Agent 启动时间
       ├── 工具调用序列
       ├── Token 消耗统计
       └── 执行结果摘要

2. 审计（Audit Trail）
   └── 完整的决策链可追溯
       ├── 为什么选择了这个方案？
       ├── 为什么跳过了那个文件？
       ├── Reviewer 发现了什么问题？
       └── 谁做了最终决策？

3. 遥测（Telemetry）
   └── 实时性能和健康监控
       ├── 上下文窗口利用率
       ├── Agent 平均响应时间
       ├── 工具调用成功率
       └── 成本消耗追踪

三次跃迁的对比

维度	Prompt Engineering	Context Engineering	Harness Engineering
核心关注	如何向 AI 提问	如何让 AI 看到全景	如何让 AI 像团队一样行动
工程师角色	提示词设计师	上下文架构师	系统线束工程师
输入	静态文本	动态上下文管道	完整的运行环境
输出	AI 文本回复	AI 基于上下文的推理	Agent 的真实行动
Agent 数量	1	1	N（多 Agent 协作）
工具使用	无	有限	完整工具集 + 权限控制
安全机制	无	无	沙箱 + 护栏 + 审计
可观测性	无	有限	完整日志 + 遥测
典型代表	ChatGPT 对话	RAG 系统、Cursor	Claude Code、Devin
类比	编剧	舞台设计师	剧院建造者

包含关系

Harness Engineering
└── Context Engineering
    └── Prompt Engineering

每一次跃迁都是在更高维度上包含前者：
- Harness Engineer 必须精通 Context Engineering（为每个 Agent 准备正确的上下文）
- Context Engineer 必须精通 Prompt Engineering（上下文的核心仍然是精心设计的指令）
- 三者不是替代关系，而是层层叠加的包含关系

实战案例：三种范式解决同一个问题

任务："为电商网站添加购物车功能"

Prompt Engineering 方案

请帮我实现一个购物车功能。技术栈是 Next.js + Prisma。
要求：
1. 用户可以添加商品到购物车
2. 可以修改数量
3. 可以删除商品
4. 显示总价

结果：AI 输出一段代码片段，但可能不符合项目现有的架构风格、API 规范、数据库设计模式。

Context Engineering 方案

context = ContextManager(project).prepare_for_task(
    "添加购物车功能"
)
# 自动注入：
# - 现有的数据库 Schema
# - API 路由模式
# - 认证中间件
# - 组件设计规范
# - 测试框架配置

结果：AI 输出符合项目规范的代码，但仍然是单一 Agent 线性输出，没有经过审查、测试和验证。

Harness Engineering 方案

[Router] 分析任务：购物车功能，涉及前端+后端+数据库

[并行] 3 个 Explorer Agent 启动
├── Explorer-1: 分析现有数据库 Schema
├── Explorer-2: 搜索现有 API 路由模式
└── Explorer-3: 查找前端组件结构

[Plan Agent] 基于探索结果设计实现方案
├── 数据库：新建 CartItem 模型
├── 后端：RESTful API 设计
├── 前端：CartDrawer 组件
└── 测试：API + 组件测试

[用户确认] 审批方案

[并行执行]
├── Coder-1: 实现 Prisma Schema 迁移
├── Coder-2: 实现购物车 API
├── Coder-3: 实现 CartDrawer 组件
└── Bash Agent: 运行数据库迁移

[Code-Reviewer] 安全审查
├── ✅ SQL 注入防护（Prisma 参数化查询）
├── ✅ 认证检查（所有 API 需要 session）
└── ⚠️ 建议添加库存检查

[Verifier] 最终验证
├── 代码质量: PASS
├── 测试覆盖: PASS（12 个测试用例）
├── 安全检查: PASS
└── 性能基准: PASS

[交付] 功能就绪

结果：一个经过完整探索、规划、实施、审查和验证的功能，质量有保障，过程可追溯。

Harness Engineer 的能力模型

成为一名 Harness Engineer 需要全新的能力组合：

1. 系统设计能力

不只是写 Prompt，而是设计系统：

- 如何分配 Agent 的职责？
- 如何控制 Agent 的权限？
- 如何设计 Agent 间的通信协议？
- 如何处理 Agent 间的冲突？
- 如何保证系统的安全性？

2. 上下文架构能力

不只是收集信息，而是设计信息流：

- 什么时候需要什么上下文？
- 如何高效利用有限的上下文窗口？
- 如何在多个 Agent 间共享上下文？
- 如何动态调整上下文的优先级？

3. 工具设计能力

不只是使用工具，而是设计工具接口：

- Agent 需要哪些工具？
- 工具的参数和返回值如何设计？
- 如何处理工具调用的失败？
- 如何防止工具被滥用？

4. 可靠性工程能力

不只是让系统工作，而是让系统可靠地工作：

- 如何检测 Agent 的错误行为？
- 如何设计降级和回滚机制？
- 如何监控系统的健康状态？
- 如何持续改进系统性能？

5. 安全工程能力

不只是写代码，而是保障安全：

- 如何防止 Agent 执行危险操作？
- 如何保护敏感数据不被泄露？
- 如何实现最小权限原则？
- 如何建立审计追踪？

未来展望

从 Harness Engineering 到什么？

如果三次跃迁的节奏继续，下一个阶段可能是：

Ecosystem Engineering（生态工程）

Harness Engineering         →    Ecosystem Engineering
单个项目的 Agent 线束           跨项目的 Agent 生态
├── 专用工具集                  ├── 通用 Agent 市场
├── 项目内协作                  ├── 跨项目 Agent 互操作
├── 单一安全模型                ├── 去中心化信任机制
└── 人工编排                    └── 自组织 Agent 网络

关键趋势

1. Agent 的商品化

随着 Harness Engineering 的成熟，构建特定能力的 Agent 会变得越来越简单。就像 Docker 让应用部署标准化一样，Harness 框架会让 Agent 创建标准化。

2. 自适应 Harness

未来的 Harness 可能会根据任务自动调整：

# 未来：Harness 自动优化自身
harness = AdaptiveHarness(codebase)
harness.learn_from_history()  # 学习过往成功模式
harness.adapt_to_task(task)   # 根据任务自动调整架构

3. 人机协作的新范式

Harness 不是要替代人类工程师，而是创造一种新的协作模式：

传统模式：
  人类 → 写代码 → AI → 审查 → 人类 → 修改 → ...

Harness 模式：
  人类 → 设定目标 → Harness → 自动执行（人类审批关键节点）→ 交付

人类从"执行者"变为"架构师和监督者"，Harness 是连接人类意图和 AI 能力的桥梁。

总结

从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，AI 工程能力的演进清晰地指向一个方向：从与 AI 对话，到为 AI 构建环境，再到为 AI 设计整个运行系统。

范式	一句话	核心能力
Prompt Engineering	向 AI 说清楚要做什么	精确表达、指令设计
Context Engineering	让 AI 看到做这件事所需的一切	信息架构、动态检索
Harness Engineering	为 AI 搭建完整的行动基础设施	系统设计、多 Agent 编排

每一次跃迁都不是抛弃前者，而是在更高层次上整合前者。Prompt Engineering 是 Harness 的最内层，Context Engineering 是 Harness 的中间层，而 Harness Engineering 将这一切包裹在一个安全、可观测、可协作的系统之中。

对于正在 AI 工程领域探索的开发者来说，理解这三次跃迁的意义在于：不要停留在某一个范式里，而要看到完整的演进图景。今天你在做的 Prompt 优化、RAG 搭建、Agent 开发，都是 Harness Engineering 这座大厦的砖石。

未来的 AI 工程师，不会只写 Prompt，不会只管上下文，而是会设计完整的 Agent Harness——让 AI 不仅能思考，还能安全、高效、可靠地行动。

延伸探索：
- Context Engineering 是新的 Prompt Engineering - Andrej Karpathy
- The "Spinning Up" of AI Engineering - Simon Willison

posted @ 2026-04-05 11:03 iTech 阅读(23) 评论(0) 收藏举报

刷新页面返回顶部

iTech's Blog

AI人工智能时代 www.theaiera.cn

从 Prompt Engineer 到 Harness Engineer：AI 工程能力的三次跃迁

从 Prompt Engineer 到 Harness Engineer：AI 工程能力的三次跃迁

引言

第一次跃迁：Prompt Engineering —— 与 AI 对话的艺术

什么是 Prompt Engineering？

核心技术手段

Prompt Engineering 的局限

第二次跃迁：Context Engineering —— 为 AI 构建认知环境

为什么需要 Context Engineering？

Context Engineering 的核心思想

关键技术维度

Context Engineering 的局限

第三次跃迁：Harness Engineering —— 构建 Agent 运行的线束

什么是 Harness Engineering？

Harness Engineering 的核心假设

Harness 的核心构成

第一层：Prompt Layer（提示层）

第二层：Context Layer（上下文层）

第三层：Tools Layer（工具层）

第四层：Orchestration Layer（编排层）

第五层：Multi-Agent Layer（多 Agent 层）

第六层：Safety & Observability Layer（安全与可观测层）

三次跃迁的对比

包含关系

实战案例：三种范式解决同一个问题

Prompt Engineering 方案

Context Engineering 方案

Harness Engineering 方案

Harness Engineer 的能力模型

1. 系统设计能力

2. 上下文架构能力

3. 工具设计能力

4. 可靠性工程能力

5. 安全工程能力

未来展望

从 Harness Engineering 到什么？

关键趋势

总结

公告