AI Agent Harness Engineering 与人类的协作模式:从副驾驶到完全自主的演进路径

你有没有过这样的体验?早上打开 GitHub Copilot,本来只想写个简单的 API 鉴权函数,结果它不仅补上了完整的 JWT 生成和验证逻辑,甚至还给你加了基于 IP 白名单的异常处理;下午和 ChatGPT-4o 视频对话,它直接把你潦草的手绘原型图转化成了 Figma 可编辑文件,还提了 3 个交互逻辑的优化点;晚上整理月度报告,LangSmith 里定制的 AI Agent 已经自动爬取了所有仓库的 PR 合并情况、单元测试通过率、线上错误日志,并生成了带趋势图和风险预警的完整分析稿——最后你只需要点一下“确认发布到公司知识库”。

这几年 AI Agent 的爆发式发展,早已让“工具人”时代的 AI 成为过去式。但很多人要么对“完全自主的通用人工智能(AGI)”抱有不切实际的期待,要么还在简单地把 AI 当成“高级搜索引擎+代码补全器”的混合体,忽略了中间至关重要的 “人机协作进化带”——而在这个进化带里,最核心、也最容易被忽视的技术领域,就是 AI Agent Harness Engineering(AI 代理缰绳工程)

引言

痛点引入:AI 协作的“冰火两重天”

如果你去技术社区逛一逛,会发现关于 AI 协作的讨论完全分裂成了两个极端:

  • “完全无用派”:他们说自己用了无数次 AI 写代码,结果不是写的代码有隐蔽的逻辑漏洞、依赖过时的 API,就是完全不符合自己的项目架构;他们和 AI 聊业务需求,聊了半小时 AI 还在问“能不能再明确一下目标用户画像的维度权重?”;甚至有团队因为盲目用 AI 生成测试脚本,导致上线前漏测了核心功能,触发了 P0 级别的事故。
  • “万能救世主派”:他们鼓吹“再过 5 年 90% 的程序员、产品经理、内容创作者都会失业”,每天晒自己用 AI 做出来的“全栈项目”“百万播放量的短视频脚本”,甚至有人说自己已经完全把工作交给了定制的 AI 集群,自己只需要每天早上看一眼报表——至于报表里的数据准不准、AI 集群会不会偷偷“搞小动作”,他们似乎完全不关心。

为什么会出现这样的分裂?核心原因不是 AI 本身的能力不够(毕竟现在 Claude 3.5 Sonnet、GPT-4o 这些模型的单模态/多模态能力已经相当强了),而是 我们还没有学会如何“有效驾驭”AI Agent——就像你给一匹野马套上了劣质的缰绳,要么它根本不听你的指挥乱跑,要么缰绳断了把你甩下来。AI Agent Harness Engineering 就是专门解决这个问题的:它研究的不是如何让 AI 变得更聪明(那是模型开发者的工作),而是 如何设计一套机制、工具和框架,让人类能够安全、高效、可控地与 AI Agent 协作,同时逐步放权,让 AI 从“只能打下手的副驾驶”,进化到“能在特定场景下独当一面的自动驾驶”,甚至未来可能实现的“通用道路上的完全自主驾驶”

解决方案概述:从“缰绳的概念”到“完整的驾驭系统”

AI Agent Harness Engineering 不是一个单一的工具或框架,而是一个 跨学科的技术领域,它融合了软件工程(特别是 DevOps、可观测性、安全工程)、人机交互(HCI)、认知科学、伦理学、经济学等多个学科的知识。

在这篇文章里,我会带你从以下几个维度系统地了解这个领域:

  1. 基础概念:什么是 AI Agent?什么是 Harness Engineering?两者之间的关系是什么?我们会用 ER 图和架构图来拆解这个系统的核心组成。
  2. 协作模式的演进路径:从“Level 0:完全人工”到“Level 5:完全自主”,我们会逐一分析每个等级的特点、适用场景、核心技术难点,以及对应的 Harness 设计原则——这部分会是文章的重点,我会用大量的行业案例、代码示例、算法流程图来帮你理解。
  3. Harness Engineering 的核心技术栈:我们会从“安全防护层”“权限管理层”“可观测性层”“反馈迭代层”“任务编排层”五个维度,逐一讲解每个层级的关键技术、主流工具,以及最佳实践。
  4. 数学模型:我们会用博弈论(特别是委托-代理模型)、马尔可夫决策过程(MDP)、强化学习中的“人类反馈强化学习(RLHF)”的变种——“人类-代理混合反馈强化学习(HMA-RLHF)”——来量化人机协作中的信任关系、权限分配策略、以及协作效率。
  5. 实践案例:我会带你一步步搭建一个 “面向开发者的 AI 代码审查代理 Harness 系统”——从环境安装、系统架构设计、接口设计,到核心代码实现,最后我们会用 LangSmith 来监控这个系统的运行效果。
  6. 常见问题与最佳实践:我们会讨论“如何评估人机协作的效率?”“如何防止 AI 代理的幻觉?”“如何处理人机之间的冲突?”这些常见的问题,并给出我的建议。
  7. 行业发展与未来趋势:我们会用一个表格来梳理 AI 协作模式的演变历史,然后展望未来 5-10 年 Harness Engineering 的发展方向。

最终效果展示:一个可落地的代码审查代理 Harness 系统

在文章的实践案例部分,我们最终会实现一个这样的系统:

  1. 人类开发者可以在 GitHub 上提交 PR,或者手动选择一个代码仓库的分支进行审查。
  2. 系统的任务编排层会自动把代码审查任务拆解成“语法检查”“逻辑漏洞扫描”“代码风格检查”“性能优化建议”“安全风险评估”五个子任务,并分配给不同的 AI 代理(比如用 DeepSeek-Coder-V2 做语法和逻辑漏洞扫描,用 SonarQube 的 AI 插件做代码风格和性能优化,用 OpenAI 的 GPT-4o Security 做安全风险评估)。
  3. 权限管理层会根据子任务的风险等级(比如安全风险评估的风险等级最高)来决定是否需要人类介入:比如语法检查的结果可以直接合并,逻辑漏洞扫描的结果需要人类开发者确认,安全风险评估的结果需要安全团队的负责人审批。
  4. 可观测性层会实时监控每个 AI 代理的运行状态、响应时间、准确性(通过与历史上的人工审查结果对比),并在 LangSmith 上生成可视化的 dashboard。
  5. 反馈迭代层会收集人类开发者和安全团队负责人的反馈(比如“这个漏洞建议是错的”“这个性能优化很好,可以推广到整个项目”),然后用这些反馈来微调每个 AI 代理的提示词,甚至用 HMA-RLHF 来微调模型本身。
  6. 安全防护层会防止 AI 代理访问敏感的代码仓库(比如生产环境的核心代码),防止 AI 代理生成恶意的代码(比如后门程序),防止 AI 代理泄露公司的商业机密(比如通过“提示词注入”的方式)。

第一章:基础概念——什么是 AI Agent Harness Engineering?

在深入探讨协作模式的演进路径之前,我们必须先搞清楚几个最核心的概念:AI AgentHarness EngineeringAI Agent Harness Engineering,以及这个系统的核心组成要素和要素之间的关系。

1.1 核心概念 1:什么是 AI Agent?

1.1.1 概念的起源与发展

“Agent(代理)”这个概念最早起源于 分布式人工智能(DAI) 领域,1986 年,美国麻省理工学院(MIT)的计算机科学家 Minsky 在他的著作《心智社会》(The Society of Mind)中提出了“心智由大量简单的代理组成”的观点——这可以看作是 AI Agent 概念的雏形。

1995 年,英国剑桥大学的计算机科学家 Wooldridge 和 Jennings 在他们的论文《Intelligent Agents: Theory and Practice》中给出了 AI Agent 的经典定义:

An AI Agent is a computer system that is situated in some environment, and that is capable of autonomous action in this environment in order to meet its design objectives.
(AI Agent 是一个位于某个环境中的计算机系统,它能够在该环境中采取自主行动,以实现其设计目标。)

这个定义里有三个非常关键的词:situated(位于环境中)autonomous(自主的)design objectives(设计目标)——这三个词是区分 AI Agent 和传统软件工具的核心标志。

1.1.2 AI Agent 的核心属性维度对比

Wooldridge 和 Jennings 在他们的论文中还给出了 AI Agent 的 四个核心属性(强代理属性),以及 四个可选属性(弱代理属性)。为了让你更清晰地理解这些属性,我整理了一个表格,对比了“传统软件工具”“弱 AI Agent(比如现在的大多数 AI 聊天机器人)”“强 AI Agent(比如 AutoGPT、BabyAGI、或者 LangChain 定制的高级代理)”在这些属性上的表现:

属性类型 属性名称 属性解释 传统软件工具 弱 AI Agent 强 AI Agent
强代理属性(必备) Situatedness(位于环境中) 能够感知环境的状态(比如通过摄像头、传感器、API 接口等),并且能够改变环境的状态(比如通过执行代码、发送邮件、控制机器人等) ✅ 可以改变环境状态,但只能感知预设的、结构化的环境状态(比如 Excel 表格的内容、数据库的查询结果),无法感知非结构化的环境状态(比如用户的手绘草图、语音指令中的情绪) ✅ 可以感知部分非结构化的环境状态(比如文本、图片、语音),但改变环境状态的能力有限(比如只能生成文本、图片、语音,无法直接执行代码、控制机器人——除非通过第三方 API 接口,且接口的使用需要人类明确授权) ✅ 可以感知几乎所有类型的环境状态(文本、图片、语音、视频、传感器数据、数据库状态、代码仓库状态等),并且可以通过内置的工具调用能力直接改变环境状态(比如自动安装依赖库、自动执行代码、自动控制机器人、自动修改代码仓库的内容等)
Autonomy(自主性) 能够在没有人类直接干预的情况下,自主地选择和执行行动 ❌ 完全没有自主性,只能执行预设的、固定的指令序列(比如 Excel 的“求和”函数、传统 CI/CD 流水线的“构建-测试-部署”步骤) ⚠️ 有有限的自主性,可以在预设的指令范围内自主选择简单的行动(比如在回答用户的问题时,可以自主选择是否需要调用网络搜索工具),但无法自主地设定长期目标、无法自主地拆解复杂任务、无法自主地修正行动策略 ✅ 有高度的自主性,可以自主地设定长期目标、可以自主地把复杂任务拆解成多个子任务、可以自主地根据环境的反馈修正行动策略(比如如果第一次执行代码失败了,它可以自主地分析失败原因、修改代码、再次执行,直到成功为止)
Reactivity(反应性) 能够及时地感知环境的变化,并对环境的变化做出快速的反应 ✅ 可以对预设的、结构化的环境变化做出快速的反应(比如传统的监控系统,如果检测到服务器的 CPU 使用率超过 90%,会立即发送告警邮件) ⚠️ 可以对部分非结构化的环境变化做出快速的反应(比如在视频对话中,如果用户突然拿出一张新的图片,它可以立即识别图片的内容),但反应的范围有限,无法对所有类型的环境变化做出反应 ✅ 可以对几乎所有类型的环境变化做出快速的反应(比如如果代码仓库里突然出现了一个新的 PR,它可以立即开始审查;如果线上错误日志里突然出现了一个新的 P0 级别错误,它可以立即开始排查原因、甚至自动回滚代码)
Pro-activeness(主动性) 不会只被动地对环境的变化做出反应,而是会主动地采取行动,以实现其长期目标 ❌ 完全没有主动性,只会被动地执行人类的指令或预设的程序 ⚠️ 有非常有限的主动性,比如某些 AI 聊天机器人会在用户长时间不说话的时候主动问一句“还有什么我可以帮你的吗?”,但这只是预设的话术,不是为了实现长期目标 ✅ 有高度的主动性,比如一个面向开发者的 AI 代码审查代理,它不会只等人类提交 PR 才开始审查,而是会主动地扫描代码仓库的分支,提前发现潜在的漏洞和安全风险;比如一个面向内容创作者的 AI 写作代理,它不会只等人类给出主题才开始写作,而是会主动地分析当前的热点话题,提前准备好相关的写作素材
弱代理属性(可选) Social Ability(社交能力) 能够与其他 AI Agent 或人类进行交互和协作(比如通过自然语言、API 接口等) ❌ 完全没有社交能力,只能与人类通过预设的 UI 界面进行交互 ✅ 可以与人类通过自然语言进行交互,但与其他 AI Agent 交互的能力有限(除非通过专门的框架,比如 LangChain 的 Multi-Agent 框架) ✅ 可以与人类通过自然语言、UI 界面等多种方式进行交互,也可以与其他 AI Agent 通过专门的协议(比如 MQTT、Kafka、或者 LangChain 的 Multi-Agent 协议)进行高效的协作
Learning Ability(学习能力) 能够从过去的经验中学习,不断提高自己的行动效率和准确性 ❌ 完全没有学习能力,除非人类手动修改代码或配置文件 ⚠️ 有有限的学习能力,比如某些 AI 聊天机器人可以通过上下文窗口记住用户的偏好,但无法长期保存这些偏好,也无法从大量的历史数据中学习 ✅ 有高度的学习能力,可以通过 RLHF、HMA-RLHF、或者迁移学习等方式,从大量的历史数据和人类/代理的反馈中学习,不断提高自己的行动效率和准确性
Adaptability(适应性) 能够适应环境的变化(比如环境的规则发生了变化、环境的状态发生了剧烈的变化),而不需要人类手动修改代码或配置文件 ❌ 完全没有适应性,如果环境的规则发生了变化,人类必须手动修改代码或配置文件 ⚠️ 有有限的适应性,比如某些 AI 聊天机器人可以适应不同的用户说话风格,但如果环境的规则发生了剧烈的变化(比如公司的 API 接口的参数格式发生了变化),它就无法正常工作了 ✅ 有高度的适应性,可以通过自主地探索环境、自主地分析环境规则的变化、自主地调整自己的行动策略,来适应环境的变化
Rationality(理性) 能够选择最优的行动,以最大化实现其设计目标的概率 ❌ 完全没有理性,只会执行预设的指令,不管这些指令是否能实现目标 ⚠️ 有有限的理性,可以在预设的指令范围内选择相对简单的最优行动,但无法处理复杂的、不确定的环境 ✅ 有高度的理性,可以通过马尔可夫决策过程(MDP)、部分可观测马尔可夫决策过程(POMDP)、或者强化学习等方式,在复杂的、不确定的环境中选择最优的行动

从这个表格里可以看出,强 AI Agent 才是真正意义上的“AI 代理”——它具备了所有的强代理属性,以及大部分的弱代理属性。而我们现在讨论的“AI Agent Harness Engineering”,主要就是针对强 AI Agent 的——因为弱 AI Agent 的自主性有限,不需要太复杂的驾驭机制。

1.1.3 AI Agent 的核心组成要素

一个完整的强 AI Agent 通常由以下 六个核心组成要素 构成(这个结构是我在 LangChain 的 Agent 结构基础上,结合了 Minsky 的《心智社会》和 Wooldridge & Jennings 的理论整理出来的):

  1. Perception Module(感知模块):负责感知环境的状态,包括文本、图片、语音、视频、传感器数据、数据库状态、代码仓库状态等。感知模块通常会包含多个子模块,比如文本感知子模块(用 OCR 识别图片中的文字、用 ASR 识别语音中的文字)、多模态感知子模块(用 GPT-4o、Claude 3.5 Sonnet 这些多模态模型理解文本、图片、语音、视频的组合内容)、环境状态感知子模块(用 GitHub API、GitLab API、AWS CloudWatch API、Prometheus API 这些第三方 API 接口感知代码仓库、服务器、数据库的状态)。
  2. Memory Module(记忆模块):负责存储 AI Agent 的历史经验、当前状态、长期目标等信息。记忆模块通常会包含三个子模块:
    • Short-Term Memory(短期记忆):也叫“上下文窗口记忆”,负责存储 AI Agent 当前正在处理的任务的相关信息,容量有限(比如 GPT-4o 的上下文窗口是 128K tokens,Claude 3.5 Sonnet 的上下文窗口是 200K tokens)。
    • Long-Term Memory(长期记忆):负责存储 AI Agent 的历史经验、用户的偏好、项目的架构等信息,容量几乎无限。长期记忆通常会用向量数据库(比如 Pinecone、Weaviate、Chroma、Milvus)来存储,因为向量数据库可以快速地检索与当前任务相关的历史信息。
    • Episodic Memory(情景记忆):负责存储 AI Agent 过去执行的具体任务的情景(比如“2024年5月10日,我帮用户审查了一个关于用户登录功能的 PR,发现了一个 SQL 注入漏洞,用户确认了我的建议,并修改了代码”),情景记忆通常会用图数据库(比如 Neo4j、Amazon Neptune)来存储,因为图数据库可以很好地表示情景之间的关系。
  3. Reasoning Module(推理模块):负责根据感知模块获取的环境状态、记忆模块存储的历史信息,以及设计目标,进行推理和决策,选择最优的行动。推理模块通常会包含多个子模块,比如逻辑推理子模块(用符号推理、逻辑编程等方式进行推理)、因果推理子模块(用因果图、贝叶斯网络等方式进行推理)、规划子模块(用 STRIPS、PDDL、或者大语言模型的 Chain-of-Thought(CoT)、Tree-of-Thought(ToT)、Graph-of-Thought(GoT)等方式进行任务拆解和规划)。
  4. Action Module(行动模块):负责执行推理模块选择的最优行动,改变环境的状态。行动模块通常会包含一个 Tool Registry(工具注册表) 和一个 Tool Executor(工具执行器)
    • Tool Registry(工具注册表):负责注册 AI Agent 可以使用的所有工具,比如网络搜索工具(Google Search API、Bing Search API)、代码执行工具(Python REPL、Node.js REPL、Docker 容器)、代码仓库操作工具(GitHub API、GitLab API)、数据库操作工具(SQLAlchemy、Prisma)、邮件发送工具(SendGrid API、Mailchimp API)等。
    • Tool Executor(工具执行器):负责根据推理模块的指令,调用相应的工具,执行相应的行动,并把执行结果返回给感知模块。
  5. Goal Module(目标模块):负责存储和管理 AI Agent 的设计目标,包括长期目标和短期目标。目标模块通常会包含一个 Goal Generator(目标生成器) 和一个 Goal Evaluator(目标评估器)
    • Goal Generator(目标生成器):负责根据人类的指令、环境的状态、以及长期目标,自主地生成短期目标。
    • Goal Evaluator(目标评估器):负责评估短期目标是否已经实现,以及长期目标的实现进度。
  6. Communication Module(通信模块):负责与其他 AI Agent 或人类进行交互和协作,包括发送消息、接收消息、解析消息、生成响应等。通信模块通常会支持多种通信方式,比如自然语言(文本、语音、视频)、API 接口(REST API、GraphQL API)、消息队列(MQTT、Kafka)等。

为了让你更清晰地理解这些组成要素之间的关系,我画了一个 AI Agent 的核心组成要素交互关系图(Mermaid 架构图)

AI Agent Core

感知状态

存储感知结果

传递感知结果

检索历史信息

存储推理结果

传递设计目标

更新目标进度

存储目标信息

选择最优行动

改变环境状态

存储行动结果

发送指令/反馈

解析指令/反馈

存储指令/反馈

生成响应/协作请求

发送响应/协作请求

发送响应/协作请求

发送协作结果

解析协作结果

存储协作结果

感知模块
Perception Module

记忆模块
Memory Module
(短期/长期/情景)

推理模块
Reasoning Module
(逻辑/因果/规划)

行动模块
Action Module
(工具注册表/执行器)

目标模块
Goal Module
(目标生成器/评估器)

通信模块
Communication Module

环境
Environment

人类
Human

其他 AI Agent
Other Agents


1.2 核心概念 2:什么是 Harness Engineering?

1.2.1 概念的起源

“Harness(缰绳/ harness)”这个词本来是指用来控制马、驴等牲畜的一套装备,包括缰绳、马鞍、马镫等——它的核心作用是 “让人类能够安全、高效、可控地驾驭牲畜,同时让牲畜能够发挥最大的作用”

后来,这个词被引入到了软件工程领域,比如:

  • Test Harness(测试 harness):是指用来自动化测试软件的一套工具和框架,它的核心作用是 “让测试人员能够安全、高效、可控地执行测试用例,同时收集测试结果和覆盖率数据”——比如 JUnit、pytest 这些测试框架都可以看作是 Test Harness。
  • Build Harness(构建 harness):是指用来自动化构建软件的一套工具和框架,它的核心作用是 “让开发人员能够安全、高效、可控地执行构建流程,同时保证构建的一致性和可重复性”——比如 Make、CMake、Gradle、Maven 这些构建工具都可以看作是 Build Harness。
  • Deployment Harness(部署 harness):是指用来自动化部署软件的一套工具和框架,它的核心作用是 “让运维人员能够安全、高效、可控地执行部署流程,同时减少部署的风险”——比如 Jenkins、GitLab CI/CD、GitHub Actions、Argo CD 这些 CI/CD 工具都可以看作是 Deployment Harness。
1.2.2 软件工程中 Harness 的核心属性

从上面的例子可以看出,软件工程中的 Harness 是一套“约束+赋能”的系统——它不是为了限制软件的能力,而是为了让软件的能力能够在人类的控制下发挥最大的作用。具体来说,软件工程中的 Harness 通常具备以下 四个核心属性

  1. Constraints(约束性):它会对软件的行为设定一系列的规则和限制,比如 Test Harness 会限制测试用例只能在沙箱环境中执行,Deployment Harness 会限制部署流程只能在测试通过后才能执行生产环境的部署。
  2. Enablement(赋能性):它会为软件提供一系列的工具和框架,帮助软件更好地完成任务,比如 Test Harness 会为测试用例提供断言库、Mock 库、覆盖率统计工具等,Deployment Harness 会为部署流程提供回滚机制、蓝绿部署、金丝雀发布等工具。
  3. Observability(可观测性):它会实时监控软件的运行状态、执行结果、性能指标等,并把这些数据可视化展示出来,比如 Test Harness 会生成测试报告和覆盖率报告,Deployment Harness 会生成部署日志和性能监控报告。
  4. Feedback Loop(反馈循环):它会收集软件的运行结果和人类的反馈,然后用这些反馈来优化软件的行为,比如 Test Harness 会收集测试失败的结果,帮助开发人员快速定位和修复 Bug;Deployment Harness 会收集线上错误日志,帮助运维人员快速回滚代码。

1.3 核心概念 3:什么是 AI Agent Harness Engineering?

1.3.1 概念的定义

现在,我们可以把“AI Agent”和“Harness Engineering”这两个概念结合起来,给出 AI Agent Harness Engineering 的定义

AI Agent Harness Engineering 是一个跨学科的技术领域,它研究的是如何设计、开发、部署和维护一套“约束+赋能+可观测+反馈”的系统,让人类能够安全、高效、可控地与强 AI Agent 协作,同时逐步放权,让 AI Agent 从“只能打下手的副驾驶”,进化到“能在特定场景下独当一面的自动驾驶”,甚至未来可能实现的“通用道路上的完全自主驾驶”。

这个定义里有几个非常关键的点:

  1. 跨学科:它融合了软件工程(特别是 DevOps、可观测性、安全工程)、人机交互(HCI)、认知科学、伦理学、经济学等多个学科的知识。
  2. 约束+赋能+可观测+反馈:它继承了软件工程中 Harness 的四个核心属性,但针对强 AI Agent 的特点进行了扩展和优化。
  3. 逐步放权:它不是一开始就把所有的权限都交给 AI Agent,而是根据 AI Agent 的能力、任务的风险等级、以及人类对 AI Agent 的信任程度,逐步放权——这是 AI Agent Harness Engineering 与传统 Harness Engineering 的最大区别(传统 Harness Engineering 的约束是固定的,不会随着时间的推移而改变)。
1.3.2 AI Agent Harness Engineering 与其他相关领域的关系

为了让你更清晰地理解 AI Agent Harness Engineering 的定位,我整理了一个 相关领域的 ER 实体关系图(Mermaid 架构图),展示了它与其他相关领域的关系:

为其提供约束和赋能机制

基于大语言模型开发

继承其自动化、可重复性的理念

继承其可观测性的理念,并针对 AI Agent 进行扩展

继承其安全防护的理念,并针对 AI Agent 的特点进行扩展(比如防止提示词注入、防止生成恶意代码)

基于其理念设计友好的人机协作界面和流程

基于其理念理解人类的认知过程,设计更符合人类习惯的协作模式

基于其理念解决人机协作中的伦理问题(比如公平性、透明度、问责制)

基于其理念解决人机协作中的经济问题(比如如何分配任务、如何评估协作效率、如何激励人类和 AI Agent)

AI_Agent_Harness_Engineering

string

name

PK

AI Agent Harness Engineering

string

goal

安全、高效、可控地人机协作,逐步放权

AI_Agent_Development

string

name

PK

AI Agent Development

string

goal

开发具备强代理属性的 AI Agent

Large_Language_Model_Development

string

name

PK

大语言模型开发

string

goal

开发性能更强的大语言模型

DevOps

string

name

PK

DevOps

string

goal

自动化软件的构建、测试、部署流程

Observability_Engineering

string

name

PK

可观测性工程

string

goal

监控软件的运行状态、执行结果、性能指标

Security_Engineering

string

name

PK

安全工程

string

goal

保护软件和数据的安全

Human_Computer_Interaction

string

name

PK

人机交互(HCI)

string

goal

设计友好的人机交互界面和流程

Cognitive_Science

string

name

PK

认知科学

string

goal

研究人类的认知过程

Ethics

string

name

PK

伦理学

string

goal

研究人机协作中的伦理问题

Economics

string

name

PK

经济学

string

goal

研究人机协作中的经济问题


1.4 AI Agent Harness 系统的核心组成要素

一个完整的 AI Agent Harness 系统通常由以下 八个核心组成要素 构成(这个结构是我在传统 Harness 系统的四个核心属性基础上,结合强 AI Agent 的特点整理出来的):

  1. Security Shield Layer(安全防护层):负责保护 AI Agent、人类、环境的安全,防止 AI Agent 访问敏感数据、防止 AI Agent 生成恶意代码、防止 AI Agent 泄露商业机密、防止提示词注入等攻击。
  2. Authorization & Access Control Layer(权限管理层):负责管理 AI Agent 的权限,根据 AI Agent 的能力、任务的风险等级、以及人类对 AI Agent 的信任程度,决定 AI Agent 可以执行哪些行动、可以访问哪些数据——这是“逐步放权”的核心层。
  3. Task Orchestration Layer(任务编排层):负责把人类的复杂指令拆解成多个子任务,分配给不同的 AI Agent(或子代理),协调子任务的执行顺序,收集子任务的执行结果,并把最终的执行结果返回给人类。
  4. Observability & Monitoring Layer(可观测性与监控层):负责实时监控 AI Agent 的运行状态、响应时间、准确性、可靠性、成本等指标,并把这些数据可视化展示出来,帮助人类快速定位和解决问题。
  5. Human-in-the-Loop Layer(人类在回路层):负责设计人类介入的机制和流程,根据任务的风险等级、AI Agent 的置信度、以及可观测性层的数据,决定何时需要人类介入、介入的方式是什么(比如确认、审批、修改、终止)。
  6. Feedback & Iteration Layer(反馈迭代层):负责收集人类的反馈、AI Agent 的执行结果、以及环境的反馈,然后用这些反馈来优化 AI Agent 的提示词、微调 AI Agent 的模型、调整权限管理层的规则、优化任务编排层的策略——这是“持续改进”的核心层。
  7. HCI Interface Layer(人机交互界面层):负责设计友好的人机交互界面和流程,让人类能够方便地给 AI Agent 发送指令、查看 AI Agent 的执行结果、给 AI Agent 提供反馈、介入 AI Agent 的执行过程。
  8. Governance & Compliance Layer(治理与合规层):负责人机协作的治理和合规问题,比如制定人机协作的规则和制度、记录人机协作的所有过程(以便审计和问责)、确保人机协作符合法律法规和公司的政策。

为了让你更清晰地理解这些组成要素之间的关系,以及它们与 AI Agent、人类、环境之间的关系,我画了一个 AI Agent Harness 系统的整体架构图(Mermaid 架构图)

AI Agent Harness System

发送指令/反馈/审批

展示执行结果/请求介入/可视化监控数据

传递指令/反馈/审批

传递指令/反馈/审批

传递反馈

查询监控数据

拆解任务/分配任务

检查权限

请求介入(如果需要)

存储执行过程

发送监控数据

决定是否介入/介入方式

存储介入过程

发送监控数据

返回权限结果

调整权限规则

检查安全性(指令/行动/数据)

检查安全性(指令/行动/数据)

调整安全规则

发送监控数据

展示监控数据

优化提示词/微调模型

调整权限规则

调整安全规则

优化任务编排策略

检查合规性

检查合规性

执行子任务/返回执行结果

发送监控数据

存储执行过程

请求安全检查

请求权限检查

感知环境状态/改变环境状态

返回环境状态/执行结果

AI Agent Cluster

AI Agent 1
(代码审查)

AI Agent 2
(网络搜索)

AI Agent 3
(代码执行)

AI Agent N
(...)

人类
Human

治理与合规层
Governance & Compliance Layer

人机交互界面层
HCI Interface Layer

反馈迭代层
Feedback & Iteration Layer

人类在回路层
Human-in-the-Loop Layer

可观测性与监控层
Observability & Monitoring Layer

任务编排层
Task Orchestration Layer

权限管理层
Authorization & Access Control Layer

安全防护层
Security Shield Layer

环境
Environment
代码仓库/服务器/数据库/...

AgentCluster


1.5 本章小结

在这一章里,我们系统地讲解了 AI Agent Harness Engineering 的基础概念:

  1. 什么是 AI Agent:我们回顾了 AI Agent 概念的起源与发展,给出了 Wooldridge & Jennings 的经典定义,对比了传统软件工具、弱 AI Agent、强 AI Agent 在核心属性维度上的表现,拆解了强 AI Agent 的六个核心组成要素(感知模块、记忆模块、推理模块、行动模块、目标模块、通信模块),并画了一个交互关系图。
  2. 什么是 Harness Engineering:我们回顾了 Harness 概念的起源(从控制牲畜的装备到软件工程中的 Test/Build/Deployment Harness),总结了软件工程中 Harness 的四个核心属性(约束性、赋能性、可观测性、反馈循环)。
  3. 什么是 AI Agent Harness Engineering:我们把前两个概念结合起来,给出了 AI Agent Harness Engineering 的定义,强调了它的“跨学科”“约束+赋能+可观测+反馈”“逐步放权”三个关键特点,并画了一个相关领域的 ER 实体关系图,展示了它与其他相关领域的关系。
  4. AI Agent Harness 系统的核心组成要素:我们拆解了 AI Agent Harness 系统的八个核心组成要素(安全防护层、权限管理层、任务编排层、可观测性与监控层、人类在回路层、反馈迭代层、人机交互界面层、治理与合规层),并画了一个整体架构图,展示了这些要素之间的关系,以及它们与 AI Agent、人类、环境之间的关系。

这一章的内容是整个文章的基础——只有理解了这些基础概念,我们才能更好地理解后面的协作模式演进路径、核心技术栈、实践案例等内容。

在下一章里,我们将进入文章的重点:AI Agent 与人类的协作模式演进路径——从 Level 0(完全人工)到 Level 5(完全自主),我们会逐一分析每个等级的特点、适用场景、核心技术难点、对应的 Harness 设计原则,以及大量的行业案例。

更多推荐