Harness Engineering 实战：从前端开发视角，让AI Agent真正落地生产

作为一名从前端开发转型做 AI Agent 开发的工程师，我踩过最痛的坑，不是"模型调参"或者"Prompt 优化"，而是把前端工程里的"规范、验证、闭环"思维丢在了脑后。最开始，我和很多人一样，觉得 Agent 开发靠"聪明的大模型 + 炫酷的工具调用"就能搞定。直到真正把 Demo 推上生产环境后才发现：前端开发里的"工程化思维"，才是让 Agent 稳定跑起来的核心。这也是我现在对 Harness Engineering 的理解。

---

一、从前端开发视角看：为什么 Agent Demo 很稳，上线就崩？

做前端时，我们最怕的一句话是：

"本地是好的。"

转型做 Agent 后，我发现这个问题几乎一模一样，只是场景换了。

本地调 Demo 时：

• Agent 能写代码
• 能调接口
• 能执行任务
• 能完成简单流程

看起来像个"会干活的 AI 工程师"。但一旦上生产，各种前端开发里熟悉的问题就开始出现。

---

1. 业务规则漏校验：像没做表单验证

前端开发里，我们不会让用户填完表单直接提交。

一定会做：

• 字段校验
• 禁用逻辑
• 规则拦截
• 边界处理

但我最早做 Agent 时，完全忘了这件事。

例如：

用户问：

"去年买的手机还能退货吗？"

Agent 查完订单后直接回复：

"已为您申请退款。"

但真实规则其实是：

• 仅支持 7 天无理由
• 用户订单已经超过 12 个月

这个问题本质上和前端没做表单校验没有区别。

模型"理解"了语言，但没有真正被业务规则约束。

后来我才意识到：

业务规则不能只靠模型理解，必须像前端校验一样，变成可执行逻辑。

就像：

if (orderTime > 7天) {
  disabled = true
}

没有这种硬约束，模型只能靠概率"猜规则"。出错是必然的。

---

2. 工具链不稳定：像前端接口没做容错

前端开发里：

• 接口失败
• 超时
• 降级
• 重试
• Loading
• Toast 提示

这些都属于基本操作。

但很多 Agent 项目只关注：

"模型会不会调工具？"

却忽略了：

"工具调用失败怎么办？"

例如用户查询发票时：

• Agent 传错用户 ID
• 接口连续失败
• 重试逻辑失控
• 最后统一回复"系统繁忙"

这和前端没做 axios 重试、异常拦截、本地兜底几乎一样。模型知道要调用哪个接口，不代表链路可靠。真正的问题不是"模型笨"，而是：

整个执行链路缺少工程化防护。

---

3. 长任务失忆：像前端没做状态管理

前端开发里：

• Redux
• Pinia
• Zustand
• localStorage

本质上都在解决一件事：

状态不能丢。

但很多 Agent 在执行长任务时，没有任何状态维护机制。

例如让 Agent 开发后台系统：

• 建数据库
• 写接口
• 写前端
• 写权限系统

做到一半后：

• 上下文被冲淡
• 中间状态没人维护
• Agent 开始逻辑断裂

最后输出一堆无法运行的代码。这和前端页面刷新后状态全丢没有区别。后来我才真正意识到：做 Agent 不是"玩模型"。而是像做前端项目一样，需要完整的工程体系：

• 约束
• 状态
• 验证
• 反馈
• 边界

这些东西，前端工程师其实早就很熟了。

---

二、从前端视角重新理解 Harness Engineering

转型前，我每天都在和前端工程化打交道：

• ESLint
• CI/CD
• 单元测试
• 状态管理
• Git Hook
• 自动部署

转型做 Agent 后，我发现：Harness Engineering 本质上就是把前端工程化思维迁移到了 AI 系统里。

---

1. Prompt / Agent / Harness 的区别

Prompt Engineering

更像前端里的：

• UI 文案
• 提示语
• 按钮描述

核心目标是：

让单次输出更好。

比如：

• Prompt 调优
• Few-shot
• 角色设定

但它解决不了系统稳定性问题。

---

Agent Engineering

更像前端从静态页面升级成 SPA：

• 有路由
• 有接口
• 有交互
• 有状态

模型开始"能执行任务"。

但依然可能失控。

---

Harness Engineering

Harness 更像完整的前端工程体系：

• ESLint
• CI/CD
• Jest
• 状态管理
• Git Flow
• 自动化测试

它真正解决的是：

如何让系统稳定跑在生产环境。

---

2. 一个前端工程师更容易理解的定义

对前端开发者来说：

Harness 本质上就是：

围绕模型运行的一整套工程化基础设施。

Harness 问题	对应前端工程化
提供可信上下文	环境变量 / 全局配置
限制行为边界	ESLint / Prettier
拆解任务	模块化开发
验证结果	单元测试 / E2E
记录状态	Redux / Pinia
错误监控	Sentry / Console
反馈闭环	CI/CD

很多人以为：

Agent = 大模型 + 工具

但实际上更接近：

Agent = 模型 + Harness

模型只是框架。

Harness 才是真正的工程基建。

---

三、为什么很多 Agent 项目最后都会失控？

这个问题，前端开发者其实特别容易理解。

因为我们见过太多：

• 没规范的项目
• 没测试的项目
• 没模块化的项目
• 越做越乱的项目

这些问题在 Agent 项目里几乎一模一样。

Agent 项目问题	本质原因	对应前端问题
AI 到处乱改代码	没有边界控制	没有 ESLint
输出风格越来越乱	没有统一规范	命名风格混乱
功能做到后期开始崩	没有任务拆分	一次性开发整个系统
改一个地方炸三个地方	没有验证闭环	改代码不跑测试
Agent 越跑越不可控	没有状态管理	页面状态混乱

我以前也以为：

"模型再强一点就好了。"

后来才发现：

模型能力提升，解决不了工程失控。

就像 Vue3 解决不了代码混乱一样。

---

四、前端开发者如何落地 Harness？

我自己的实践方式其实很简单：

把前端工程化体系，直接迁移到 Agent 开发里。

核心分五层。

---

4.1 上下文架构：给 Agent 写 README

做前端项目时：

我们会写：

• README.md
• CONTRIBUTING.md
• 开发规范
• 提测清单

Agent 项目也一样。

我通常会建立：

AGENTS.md

例如：

# 项目规范

## 提测前必须执行

1. npm run build
2. npm run lint
3. npm run test

## 技术栈

- React 18
- TypeScript
- FastAPI

## 强制规则

- 禁止跨层调用
- 所有 Props 必须定义类型
- 公共组件必须写注释

但要注意：

规则文件不是保险箱。

模型会：

• 忽略规则
• 遗忘规则
• 选择性遵守规则

所以：

真正可靠的，必须是自动化校验。

---

4.2 工具系统：给 Agent 装"手和脚"

大模型本身只会输出文本。

所以必须给它执行能力。

这一步对前端开发者来说很好理解。

Agent 工具	作用	对应前端操作
Bash	执行命令	npm run dev
文件系统	修改代码	VS Code
Browser	测试页面	Chrome 调试
Search	查询资料	MDN / React Docs
Git	管理版本	commit / revert

另外我会接入 MCP：

• Firecrawl MCP
• Context7 MCP

让 Agent 自动查询最新文档。

因为很多问题不是模型不会。

而是：

它用了过期知识。

---

4.3 任务编排：像前端迭代一样拆功能

前端开发不会一口气做完整个平台。

通常都是：

• 登录页
• 用户列表
• 权限系统
• 数据统计

一步一步迭代。

Agent 也一样。

现在我会把任务拆得非常细。

例如：

第一步：只完成登录页面 UI
第二步：只接登录接口
第三步：只实现 JWT 鉴权
第四步：只做用户列表

每次只允许 Agent 做一个明确目标。

同时我会维护进度文件：

# 当前进度

## 已完成
- 登录页面
- JWT 鉴权

## 待完成
- 用户列表
- 分页功能

否则新开会话后：

Agent 就像页面刷新一样直接失忆。

---

4.4 反馈闭环：像前端 CI/CD 一样自动验证

这是 Harness 最重要的一层。

也是前端工程师最容易上手的一层。

核心原则非常简单：

永远不要相信 Agent 说"已完成"。

必须自动验证。

---

最基础的验证链路

生成代码
→ npm run build
→ npm run lint
→ npm run test
→ E2E 测试
→ 人工确认

任何一步失败：

都不允许结束任务。

---

更进一步：让 Agent 自己调试

例如测试失败：

Expected status 200
Received 500

让 Agent：

1. 读取日志
2. 分析问题
3. 修复代码
4. 重新验证

这时候它才真正进入"工程循环"。

---

4.5 架构护栏：禁止 AI 把项目越改越乱

AI 有个很危险的问题：

它会学习仓库里的坏代码。

而且还会把问题放大。

所以必须建立架构级约束。

---

1. 禁止跨层调用

UI 层 → hooks 层 → API 层
禁止 UI 层直接调 API

---

2. 强制依赖方向

页面组件 → 公共组件 → 工具函数
禁止反向依赖

---

3. 禁止重复逻辑

重复请求逻辑必须抽：

• hooks
• utils
• service

这些约束不能只是建议。

必须像：

• ESLint
• husky
• pre-commit

一样强制执行。

---

五、Harness 的成熟度分层

不是所有团队都需要：

• 全自动 Agent
• 多 Agent 自治系统

大部分团队先做到 Level 2 就够了。

等级	特点	对应前端工程化
Level 0	只会写 Prompt	原生 HTML
Level 1	有规则文件	有 README
Level 2	有自动验证	ESLint + CI
Level 3	多 Agent 协作	微前端
Level 4	自治系统	全自动流水线

真正最重要的是：

Level 2：反馈闭环

因为真正让代码可信的，从来不是模型。

而是：

• 测试
• CI
• Hook
• Linter
• Review

这些传统工程体系。

---

六、前端工程经验，其实是 Agent 开发的重要优势

转型前，我也担心过：

"前端经验会不会过时？"

后来发现恰恰相反。

越懂前端工程化的人：

往往越容易把 Agent 项目做稳定。

因为 Harness Engineering 本质上并不新。

它只是把前端开发里的：

• 测试
• 规范
• 状态管理
• 自动化验证
• 流程控制

重新应用到了 AI 系统里。

例如：

• 用状态管理解决 Agent 失忆
• 用 CI/CD 解决结果验证
• 用 ESLint 解决行为边界
• 用任务拆分解决上下文爆炸

这些东西，前端工程师本来就很熟。

---

七、最后：未来拼的不是 Prompt，而是工程体系

现在越来越明显的一件事是：

未来 Agent 项目的竞争力，拼的不是：

"谁 Prompt 写得更花。"

而是：

"谁更像一个成熟的软件工程团队。"

模型能力会不断提升。

但真正拉开差距的：

• 是工程规范
• 是验证闭环
• 是状态管理
• 是任务拆分
• 是架构约束

这些东西，本质上全是工程能力。

而这恰恰是前端开发者最熟悉的老本行。

说到底：

真正让 Agent 落地生产的，从来不是"大模型有多聪明"。

而是：

你有没有把软件工程真正做好。

这也是我现在对 Harness Engineering 最真实的理解。