本文不是 Claude Code 的逐行源码解读，而是把 Claude Code 这类 Coding Agent 作为观察对象：它为什么不只是一个"更会写代码的模型"，而是一套能读文件、调工具、控权限、跑验证、做恢复的 Agent Harness？
本文站在前端工程师视角，把这些能力抽象成一套可学习、可复用的 Agent 工程化笔记，回答一个核心问题：如果未来软件研发从"人写代码"逐步变成"人定义目标，Agent 编排工具完成任务"，前端工程师应该理解哪些底层机制？
0. 阅读路线
这篇文章按"从概念到系统"的顺序组织：
text
1. 为什么前端工程师需要理解 Agent Harness
2. Agent 的核心不是神奇 Prompt，而是模型 + Harness
3. 四类 Engineering：Prompt / Context / Harness / Loop
4. 一个 Coding Agent Harness 需要哪些机制
5. 如何设计一个从需求到代码交付的 Coding Agent
6. Agent + 向量数据库 / AI 搜索如何落地
7. AI 提效如何从 Skill 升级到 Harness
8. 前端基建经验如何迁移到 AI Native / Agent 产品化
9. 最小 Demo 可以怎么做如果只想快速复习，优先看：
text
第 2 章：Agent = 模型 + Harness
第 3 章：四类 Engineering
第 4 章：Coding Agent Harness 机制导览
第 5 章：Coding Agent 系统设计
第 6 章：AI 搜索 / 向量数据库 / Agent 工程化
第 8 章：前端工程师的迁移价值与 AI Native 产品化1. 为什么前端工程师需要学 Agent Harness
过去前端工程师更多关注页面、组件、工程化、性能优化和用户体验。但 AI 编程工具快速发展后，前端的工作边界正在变化：
text
过去：人理解需求 -> 人写代码 -> 人测试 -> 人上线。
现在：人和 AI 协同写代码，AI 已经能完成大量局部实现。
未来：人定义目标、约束和质量标准，Agent 编排工具完成实现、验证和反馈。这并不意味着前端工程师只需要学会"写 Prompt"。相反，越是复杂真实的研发场景，越需要工程师理解：
text
模型能调用哪些工具？
模型看到哪些上下文？
危险操作如何拦截？
生成代码如何验证？
长任务如何不跑偏？
失败以后如何恢复？
多人/多 Agent 协作如何隔离？
外部系统如何接入？这些问题背后，就是 Agent Harness。
前端工程师过去做的很多工程化能力，比如构建工具链、组件规范、自动化测试、错误监控、性能指标、开发者平台，本质上都和 Harness 思维接近：不是只写某个功能，而是搭一个让功能稳定运行、可观测、可迭代的环境。
2. Agent 的本质：模型 + Harness
Agent 的核心可以先压缩成一句话：
text
Agent = 具备推理和决策能力的模型 + 让模型能行动、受约束、可验证的 Harness。模型负责推理、规划、选择下一步动作；Harness 负责给模型提供环境：
| 组成 | 作用 | 例子 |
|---|---|---|
| Tools | 让模型能行动 | 读文件、写文件、搜索代码、跑测试、查日志 |
| Context | 让模型知道当前任务相关信息 | 代码片段、需求文档、历史 PR、规范、错误日志 |
| Permission | 限制模型能做什么 | 禁止危险命令、写入边界、人工审批 |
| Evaluation | 判断结果是否正确 | lint、typecheck、unit test、E2E、构建、线上指标 |
| Memory | 沉淀长期知识 | 用户偏好、团队规范、项目约定、历史失败经验 |
| Loop | 让模型多轮执行 | plan -> act -> observe -> repair -> stop |
| Protocol | 让外部工具可接入 | MCP、内部平台 API、CI/CD、监控系统 |
所以，真正的 Agent 工程不是简单把模型回答包成流程节点，而是构建一个可执行、可约束、可观察、可恢复、可扩展的工程系统。
2.1 Agent 和工作流有什么区别
固定工作流适合确定性任务，例如：
text
输入文件 -> 格式转换 -> 上传 -> 发通知Agent 适合目标明确但路径不完全固定的任务，例如：
text
修复一个线上白屏问题。
实现一个需求并补齐测试。
分析一段异常日志并给出修复方案。
根据设计稿生成页面并自动检查交互。区别不在于 Agent 更"玄学"，而在于它需要根据观察结果不断调整路径：
text
第一次测试失败 -> 读取错误日志 -> 定位相关文件 -> 修改代码 -> 再跑测试 -> 仍失败 -> 换一种修复思路 -> 最终收敛。因此，Agent 不是替代确定性脚本。恰恰相反，好的 Agent 应该大量复用确定性工具，把不确定性限制在规划、判断和异常处理上。
3. 四类 Engineering：Prompt / Context / Harness / Loop
在 Agent 系统里，可以把工程能力拆成四类：
| 类型 | 解决的问题 | 典型实践 |
|---|---|---|
| Prompt Engineering | 让模型理解角色、目标、约束和输出格式 | system prompt、few-shot、结构化输出、schema |
| Context Engineering | 决定给模型什么信息，不给什么信息 | 代码检索、文档召回、上下文压缩、引用来源 |
| Harness Engineering | 让模型能安全调用工具并验证结果 | tool runtime、permission、sandbox、test、MCP |
| Loop Engineering | 让 Agent 能多轮执行、观察、修复和停止 | plan、act、observe、retry、stop condition |
这四类能力不是互斥的，而是层层递进：
text
Prompt 解决"怎么说清任务"；
Context 解决"模型应该看什么"；
Harness 解决"模型能安全做什么"；
Loop 解决"模型如何持续推进直到收敛"。一个只能写 Prompt 的系统，很容易停留在"AI 辅助问答"。一个有 Harness 和 Loop 的系统，才有机会变成真正能完成工程任务的 Agent。
4. 一个 Coding Agent Harness 需要哪些机制
前面几章回答的是"Agent 是什么"。这一章换一个角度：如果真的要做一个能在工程环境里工作的 Coding Agent，围绕最小主循环，需要逐步补齐哪些机制？
第一次使用 Claude Code 这类工具时，最直接的感受可能是"它能帮我改代码"。但真正值得拆开的不是这句体验描述，而是它为什么能在一个真实仓库里持续工作：它需要让模型看见正确上下文，能调用合适工具，知道哪些操作不能做，改完以后还能通过测试、日志或人工反馈判断结果是否可靠。
把这些能力放在一起看，Coding Agent Harness 至少要解决八类问题：行动能力、权限边界、任务规划、上下文管理、知识加载、错误恢复、协作隔离和外部系统接入。
主循环本身很简单：模型接收上下文，决定是否调用工具；工具执行后把结果反馈给模型；模型继续下一轮判断。真正的工程复杂度，不在这个 loop 有多花哨，而在 loop 周围的工具、权限、上下文、记忆、任务、协作和评测是否成熟。
4.1 从最小闭环开始：让模型能行动
最小 Agent 可以理解成一个不断重复的循环：
text
messages -> LLM -> tool_use -> execute tool -> tool_result -> messages只有这个循环时，模型还只是"会决定下一步"的大脑。它要真正做事，还需要工具系统。工具不应该只是随便拼一段 shell，而应该有清晰的输入 schema、执行 handler 和错误返回。比如读文件、写文件、搜索代码、运行测试，最好都变成结构化工具。
这样做的价值是：模型负责选择动作，Harness 负责可靠执行动作。新增工具时，不应该改 Agent 主循环，而应该注册新的工具描述和处理函数。主循环越稳定，周边能力越容易扩展。
4.2 先有边界，再谈自动化
一旦 Agent 能执行命令和改文件，权限就变成第一优先级。安全不能靠模型"自觉小心"，必须由 Harness 在工具执行前硬拦截。
一个基本权限系统至少要回答三件事：
text
哪些操作永远禁止？
哪些操作可以自动执行？
哪些操作必须让人确认？例如删除文件、访问网络、修改归档目录、安装依赖、发布上线，都不应该和普通读文件同一个权限级别。权限系统的意义不是限制 Agent 变弱，而是让它可以在可信边界内更大胆地自动化。
Hook 是权限和审计的自然扩展。用户输入进入模型前、工具执行前、工具执行后、循环结束前，都可以挂 Hook。这样日志、审计、权限、格式化、报告生成这类横切逻辑，不必塞进主循环。
4.3 长任务需要计划、隔离和压缩
短任务可以靠上下文临时记住目标，长任务不行。任务一长，Agent 很容易读了很多文件后忘掉最初目标，或者被中间错误带偏。
所以第一个要补的是计划能力。TodoWrite 这类机制的价值，不是让模型更聪明，而是让模型把当前任务拆成可见步骤，并持续更新状态：哪些待做，哪些进行中，哪些已经完成。它相当于当前会话里的轻量任务板。
第二个要补的是子任务隔离。复杂排查、批量搜索、长文档总结，可以交给子 Agent 在独立上下文里完成。主 Agent 只接收摘要，避免被大量中间过程污染。
第三个要补的是上下文压缩。Agent 工作一段时间后，工具输出、文件内容、报错日志会迅速填满窗口。好的 Context Engineering 不是"把所有东西都塞进去"，而是决定：什么应该保留在上下文里，什么应该落盘，什么可以摘要，什么需要时再重新读取。
4.4 知识不要全塞进 prompt，要按需加载
真实项目里会有大量规范：代码风格、测试规范、接口约定、业务知识、发布流程。如果这些内容每轮都塞进 system prompt，既浪费 token，也会干扰当前任务。
Skill Loading 的思路是两层加载：
text
启动时：只告诉模型有哪些 skill，以及每个 skill 什么时候用。
需要时：再加载完整 SKILL.md，让模型读取具体步骤和约束。Skill 不是简单的"提示词文件"。一个好的 Skill 应该包含触发条件、需要的上下文、执行步骤、可用工具、输出格式、校验方式和常见失败处理。它把经验变成可发现、可复用、可评估的能力包。
Memory 则解决另一类问题：跨会话的长期知识。它不应该保存所有聊天记录，而应该保存未来还会用到的稳定事实，比如用户偏好、项目约定、历史踩坑、常用入口和验证策略。
4.5 Prompt 不是硬编码，而是运行时组装
在简单 demo 里，system prompt 可以是一段固定字符串。但真实 Agent 的能力是动态的：当前有哪些工具、加载了哪些 skill、命中了哪些 memory、工作目录是什么、权限模式是什么，都可能变化。
因此 Prompt Engineering 在 Agent 系统里会升级为 Prompt Assembly：Harness 根据当前运行状态，把身份、工具、工作区、记忆、权限、任务目标等 section 组装成最终 prompt。
这个设计的好处是：prompt 不再是一大块难维护文本，而是一个运行时产物。工具变化、项目变化、权限变化，都能反映到模型看到的上下文里。
4.6 错误恢复是工程可用性的分水岭
只会跑 happy path 的 Agent 很容易演示成功，但很难生产可用。真实环境里会遇到限流、超时、模型过载、输出截断、上下文过长、测试失败、权限不足等问题。
Error Recovery 要做的是把错误分类：
text
可重试：网络抖动、临时限流、服务过载。
可降级：模型不可用、工具不可用、上下文过大。
需修复：测试失败、类型错误、lint 错误。
需人工接管：权限不足、连续失败、高风险操作。失败不是循环的终点，而是下一轮观察的输入。但这不意味着无限重试。成熟 Harness 必须有最大轮次、最大成本、超时和停止条件。
4.7 从单 Agent 到团队协作
当任务变成项目级，单个 Agent 会受上下文、时间和并行度限制。此时需要任务系统、后台任务、多 Agent 协作和工作区隔离。
任务系统负责把大目标拆成可持久化的任务图，记录状态、依赖、负责人和阻塞关系。后台任务负责处理安装依赖、构建、测试这类慢操作，让主 Agent 不必干等。多 Agent 团队负责把搜索、实现、测试、总结等工作拆给不同执行者。
但多 Agent 的难点不是"多开几个模型"，而是通信协议、任务归属、权限传递、结果汇总和冲突处理。多个 Agent 同时改代码时，还需要 worktree 这类工作区隔离，否则很难审查、回滚和归因。
4.8 MCP 把外部系统接进工具池
一个 Agent 不可能内置所有工具。公司里的知识库、CI、监控、发布、工单、设计稿、搜索服务，都需要一种标准方式接入。
MCP 可以理解为 Agent 的外部工具协议：
text
Agent 作为 MCP Client
外部服务作为 MCP Server
通过 tools/list 发现工具
通过 tools/call 调用工具它的价值不是"多一种插件形式"，而是让外部系统进入同一个工具池。模型不需要知道工具背后是本地脚本、远程服务还是公司内部平台，只需要根据 schema 调用，再根据结果继续推理。
4.9 所有机制最后都回到一个 Harness
把这些机制放在一起，一个完整 Coding Agent 的运行链路大致是：
text
用户输入
-> 输入 Hook
-> 加载任务、memory、skill、工具状态
-> 必要时做 context compact
-> 组装 prompt
-> 调用模型
-> 解析 tool_use
-> 权限检查
-> 工具执行
-> 工具结果和错误恢复
-> 输出报告或进入下一轮所以，成熟 Agent 的复杂度不是另一个"智能大脑"，而是成熟 Harness。模型提供推理和决策能力；Harness 提供工具、上下文、权限、记忆、评测、协作和恢复能力。
一句话总结这一章：
text
主循环让 Agent 活起来，Harness 让 Agent 在真实工程里可靠地活下去。5. 如何设计一个从需求到代码交付的 Coding Agent
如果要设计一个"输入需求文档，自动产出代码并验证质量"的 Coding Agent，可以拆成八层。
5.1 需求结构化
用户输入不能直接丢给模型写代码，应该先结构化成：
text
目标是什么
背景是什么
验收标准是什么
影响范围是什么
有哪些约束
有哪些风险
哪些信息缺失需要反问如果关键字段缺失，Agent 应该先反问，而不是直接实现。
5.2 上下文检索
Agent 需要构建最小必要上下文：
text
相关代码文件
相关组件和路由
接口定义
测试用例
历史 PR
团队规范
线上日志和监控
设计稿或产品文档这里的关键不是"召回越多越好"，而是"召回足够相关、可引用、可验证的上下文"。
5.3 方案规划
在改代码前，Agent 应该先输出计划：
text
要改哪些文件
为什么改这些文件
任务如何拆分
测试计划是什么
风险点在哪里
哪些步骤需要人工确认这一步类似工程师写技术方案，只是由 Agent 辅助生成。
5.4 工具执行
Agent 不应该靠自由文本"猜测"环境，而应该调用确定性工具：
text
rg / AST 搜索代码
read_file / edit_file 修改文件
lint / typecheck / unit test / e2e 验证
浏览器自动化检查页面行为
日志系统查看线上错误
CI/CD 系统触发构建或预览5.5 自动评测
生成代码质量不能只看模型解释是否合理，必须看真实执行结果：
text
lint 是否通过
typecheck 是否通过
unit test 是否通过
E2E 是否通过
构建是否通过
关键页面是否可交互
核心指标是否劣化5.6 错误恢复
工具失败后，Agent 要把失败当作观察结果，而不是终点：
text
读取错误信息
定位失败原因
判断是否可以自动修复
修改后重跑验证
超过最大轮次后交给人工5.7 权限和安全
Agent 的执行边界必须清晰：
text
工作区写入边界
危险命令拦截
敏感文件保护
外部 API 权限控制
高风险操作人工审批
可回滚策略5.8 上线反馈
真正的闭环不止到代码合并，还要看线上结果：
text
错误率
白屏率
接口失败率
性能指标
转化指标
用户反馈
灰度表现一句话总结：
text
Coding Agent 不是模型直接改代码，而是模型在受控上下文、受控工具、受控权限和受控评测里做多轮工程决策。6. Agent + 向量数据库 / AI 搜索
Agent 需要上下文，向量数据库是构建上下文的一种方式，但不是所有场景都必须上向量库。
6.1 基础链路
text
文档/代码切分
-> 生成 embedding
-> 写入向量数据库
-> 用户问题向量化
-> TopK 召回
-> rerank 重排
-> 拼接最小必要上下文
-> LLM 生成答案/计划/代码
-> 工具验证
-> 用户反馈反向优化6.2 代码场景不能只靠向量检索
代码和普通文档不同，代码有大量精确符号和依赖关系：
text
函数名
类名
组件名
路由
接口名
类型定义
调用链
依赖图所以代码 Agent 更适合混合检索：
text
关键词 / 符号检索：找准具体位置
向量检索：补充语义相关文档和历史经验
AST / 依赖图：扩展影响范围
历史 PR / issue：补充修改背景6.3 调优重点
| 调优点 | 说明 |
|---|---|
| Chunk 切分 | 代码尽量按函数、类、组件、路由、测试文件切分，不要只按固定长度切 |
| Metadata | repo、路径、语言、模块、owner、更新时间、是否测试文件、依赖关系 |
| 混合检索 | vector + keyword + AST + dependency graph |
| Rerank | 初召回后再判断片段和当前任务的真实相关性 |
| 去重和压缩 | 不把重复内容塞进上下文，保留引用来源 |
| 权限过滤 | 向量库统一存储不能绕过权限体系 |
| 反馈闭环 | 记录哪些召回真正被使用，哪些导致错误 |
6.4 什么时候不需要向量数据库
小项目、符号明确、查询更多是精确定位时，可以先用：
text
rg
文件索引
AST
依赖图
普通数据库向量数据库更适合：
text
非结构化知识多
语义查询多
历史经验多
召回范围大
需要跨文档关联6.5 AI 搜索与 Agent 工程化核心问题
这一节从 AI 搜索切入，把前面讲到的 Context、Harness、Loop、Evaluation 放到一个更贴近产品的场景里看。搜索不是简单的"向量库 + LLM"，Agent 也不是简单的"模型 + Prompt"。两者真正落地时，都要面对召回、排序、上下文组织、工具执行、权限、安全、评测和反馈闭环。
6.5.1 核心问题一：四类 Engineering 在 AI 搜索里如何落地
第 3 章已经把 Prompt、Context、Harness、Loop 的边界讲清楚了。放到 AI 搜索场景里，重点不再是重复定义概念，而是看它们分别落到链路里的哪一层。
| AI 搜索环节 | 对应 Engineering | 关键问题 |
|---|---|---|
| Query 理解和输出约束 | Prompt Engineering | 用户到底想找攻略、商品、经验、对比，还是决策建议？生成结果要按什么结构输出？ |
| 多路召回和上下文组织 | Context Engineering | 哪些内容、用户行为、业务规则、历史反馈应该进入上下文，哪些应该过滤掉？ |
| 工具调用和安全控制 | Harness Engineering | 检索、排序、RAG、风控、日志、实验平台如何被模型安全调用和审计？ |
| 反馈驱动的迭代 | Loop Engineering | 结果不好时，系统如何改写 query、重新召回、调整排序、降级或请求人工介入？ |
学习结论：AI 搜索不能只优化提示词，也不能只接一个向量库。Prompt 决定模型怎么理解任务，Context 决定模型依据什么生成，Harness 决定工具和权限怎么运行，Loop 决定系统如何根据反馈继续调整。
6.5.2 核心问题二：AI 提效是不是只做 Skill
Skill 的价值是沉淀可复用经验：什么时候触发、需要哪些输入、执行步骤是什么、如何输出、如何校验。但 Skill 通常只覆盖单类任务，还不是完整 Harness。
更完整的升级路径是：
text
Prompt 模板 -> Skill -> Tool Runtime -> Agent Loop -> Evaluation -> Memory -> Team Harness学习结论：Skill 解决"经验复用"，Harness 解决"稳定执行"。AI 提效的深水区不是让模型多生成几段代码，而是把人的判断、质量标准和工程流程沉淀成模型可以调用、可以验证、可以反馈优化的系统。第 7 章会用"生成单测"再展开这个升级过程。
6.5.3 核心问题三：不懂代码的人提需求，Agent 怎么产出功能并保证质量
这个问题本质上是"需求到上线"的 Agent 系统设计。可信的系统不能从"让模型直接写代码"开始，而要从结构化需求和验收标准开始。
可以拆成六层：
- 需求澄清：把自然语言需求解析成用户故事、页面/接口变更、验收标准、边界条件、非功能指标和不确定问题。信息不够时先反问。
- 上下文构建：用 rg、AST、依赖图、文档检索、历史 PR、监控和团队规范构建最小必要上下文。
- 方案计划：输出影响面、文件列表、接口协议、测试计划和风险点，关键决策给人确认。
- 工具执行：读写文件、生成 patch、跑 lint/typecheck/unit/e2e/build，工具必须有 schema、超时、错误返回和权限控制。
- 验证修复：失败日志作为下一轮 observe 输入，允许有限轮次修复，超过成本或风险阈值就人工接管。
- 上线反馈：灰度后绑定白屏率、JS error、接口失败率、LCP、点击率、转化率、用户反馈等指标。
学习结论：需求到上线 Agent 的关键不是"自动写完"，而是"每一步都有可验证的契约"。模型负责推理和生成，Harness 负责上下文、工具、权限、测试、监控和停止条件。这个问题和第 5 章的 Coding Agent 设计是一件事：把自然语言需求变成可执行、可验证、可回滚的工程流程。
6.5.4 核心问题四：AI 搜索系统怎么做召回、排序、生成和反馈
AI 搜索不是普通问答，它要理解用户意图、内容生态和平台指标。可以按链路拆：
text
Query 理解
-> 多路召回
-> 粗排 / 精排
-> RAG 组织上下文
-> 生成答案或搜索摘要
-> 安全和质量校验
-> 用户反馈和实验评测关键环节：
- Query 理解：识别用户是找攻略、商品、经验、地点、对比还是决策建议；必要时做 query rewrite。
- 多路召回：关键词召回、向量召回、标签/话题召回、用户兴趣召回、热门内容召回可以并存。
- 排序：不仅看语义相关，还要看内容质量、时效性、互动质量、作者可信度、个性化匹配和业务规则。
- RAG 生成：生成答案时要引用可靠内容，避免把低质量笔记放大成确定结论。
- 反馈闭环：点击、停留、收藏、转化、追问、负反馈、举报、无结果率都能反向优化召回和排序。
学习结论：AI 搜索不是"向量库 + LLM"这么简单。向量检索只是上下文构建的一种方式，真正的系统要同时处理结构化信号、语义信号、用户行为、内容质量和生成安全。工程上可以按 query 理解、多路召回、排序、RAG 生成、反馈评测五层拆解，再用点击率、无结果率、满意度、延迟和成本持续评估。
6.5.5 核心问题五：评测指标怎么设计
评测是 AI 搜索和 Agent Harness 的共同重点。没有评测，模型回答看起来再合理，也无法证明系统真的变好。
AI 搜索可以分四类指标：
| 指标类型 | 例子 | 说明 |
|---|---|---|
| 相关性 | 召回率、NDCG、MRR、人工标注相关性 | 搜到的内容是否真的回答用户问题 |
| 用户行为 | CTR、停留时长、收藏/点赞/关注、追问率 | 用户是否愿意继续消费结果 |
| 体验质量 | 无结果率、首屏延迟、生成延迟、坏例率 | 搜索是否快、稳、少翻车 |
| 业务和安全 | 转化、投诉、举报、合规拦截、成本 | 是否符合平台目标和风险边界 |
Coding Agent / 工程 Agent 可以对应四类指标：
| 指标类型 | 例子 |
|---|---|
| 正确性 | lint、typecheck、unit test、e2e、build |
| 稳定性 | 回归率、失败重试次数、线上错误率 |
| 效率 | 完成时间、token 成本、工具调用次数、人工介入次数 |
| 质量 | diff 大小、可读性、覆盖率、风险项、review 通过率 |
学习结论：Agent 的评测不能只看"模型有没有答对"，而要看任务结果是否被确定性工具、线上指标和用户反馈验证。AI 搜索的评测也不能只看语义相关，要同时关注用户行为、体验、安全和成本。
6.5.6 核心问题六：怎么避免幻觉、错误修改、无限循环和权限风险
Agent 风险不是靠模型自觉解决，而要靠 Harness 设计边界。
可落地的控制点：
- 上下文引用：回答或修改必须能追溯到检索片段、文件路径、日志或测试结果。
- 工具白名单：只允许读写指定目录、运行指定命令；危险操作要人工确认。
- 小步执行：一次只改一个目标，改完看 diff 和验证结果。
- 停止条件：限制最大轮次、最大 token、最大失败次数、最大执行时间。
- 失败降级：连续失败后输出报告和人工接管建议，而不是继续盲修。
- 验证门禁：没有 lint/test/build/指标结果，不允许声称任务完成。
- 审计回放：保留 task、context、plan、report，方便复盘为什么这么改。
学习结论：权限、安全、成本和停止条件是 Harness 的硬边界。模型负责建议下一步，Harness 负责判断这一步能不能做、做完算不算通过。一个可上线的 Agent 不能无限自由执行，它只能在白名单工具和目录里行动，每轮都要产生可观察结果，连续失败后要进入降级或人工接管。
6.5.7 小结：AI 搜索为什么适合理解 Agent 工程化
AI 搜索把 Agent 工程化里的几个关键问题集中到了一起：上下文从哪里来、结果怎么生成、质量怎么评估、风险怎么控制、反馈怎么回流。理解这条链路后，再看 Coding Agent、AI 提效或 AI Native 产品，就会发现它们面对的是同一类工程问题：让模型在正确上下文、受控工具、明确权限和可验证指标里工作。
7. AI 提效：从 Skill 到 Agent Harness
很多团队一开始做 AI 提效，都会从 Skill 或 Prompt 模板开始，例如：
text
生成单测
排查 JS 异常
生成接口文档
扫描语法兼容问题
辅助 Code Review这一步有价值，但还不等于 Agent Harness。
7.1 Skill 解决什么
Skill 适合沉淀"可复用的任务经验"：
text
什么时候使用
需要哪些输入
执行步骤是什么
调用哪些工具
输出格式是什么
如何校验结果
常见失败怎么处理它比"脚本 + 说明文档"更进一步，因为它把触发时机、上下文选择、工具编排、输出约束都结构化了。
7.2 Harness 解决什么
Harness 要解决的是完整闭环：
text
任务进入系统
上下文自动检索
模型选择工具
工具执行被权限约束
结果被测试和指标验证
失败可以重试或降级
经验可以进入 Memory所以 AI 提效的升级路径可以是：
text
Prompt 模板
-> Skill
-> 确定性工具
-> Agent Loop
-> 自动评测
-> Memory / Feedback
-> 团队级 Harness 平台7.3 例子：AI 生成单测如何升级
低阶做法：
text
给模型一段代码，让它生成单测。更工程化的做法：
text
1. 检索被测函数、调用方、已有测试风格。
2. 让模型生成测试计划，而不是直接写代码。
3. 生成测试用例，覆盖正常、边界、异常、回归。
4. 自动运行测试和覆盖率。
5. 根据失败信息修复测试或实现。
6. 输出报告：新增覆盖、失败原因、风险点。
7. 把常见模式沉淀为 Skill / Memory。这才是从"AI 帮我写测试"升级到"Agent 驱动的测试闭环"。
8. 前端工程师如何迁移到 Agent 工程化
前端工程师并不是只能做页面。很多前端工程化能力可以迁移到 Agent Harness。
| 前端/基建经验 | 可迁移到 Agent 的能力 |
|---|---|
| 构建工具链 | Tool Runtime、任务编排、依赖分析 |
| 性能优化 | 指标体系、实验设计、收益归因 |
| 自动化测试 | Evaluation、质量门禁、失败反馈 |
| 异常监控 | Observation、Error Recovery、线上反馈 |
| 开发者平台 | Agent 平台、Skill 管理、MCP 接入 |
| 组件规范 | 结构化输出、代码生成约束、设计系统验证 |
| 跨团队协作 | 多业务接入、权限边界、平台化推广 |
8.1 前端视角的独特优势
前端工程师天然贴近用户体验，也熟悉从代码到真实页面的链路：
text
组件是否正确渲染
交互是否符合预期
加载性能是否达标
错误是否可观测
UI 是否符合设计稿
多端兼容是否稳定这对 Web / AIGC / AI Native 产品里的 Agent 很重要。因为模型生成代码只是第一步，最终还要在浏览器里真实跑起来、点得动、看得对、性能不差。
8.2 还需要补齐的能力
站在前端转 Agent 的角度，短板通常在：
text
后端工程体系
Python 工程能力
MCP Server 实战
向量数据库和检索调优
Agent 评测体系
云基础设施和沙盒环境这些不是一两天就能完全补齐，但可以通过一个最小 Demo 建立可信的工程闭环。
8.3 AI Native 前端到 Agent 产品化
Agent Harness 不只服务 Coding Agent，也服务真实 AI 产品。前端在这里的价值，不是把模型 API 接到页面上，而是把不确定的模型能力变成用户可理解、可中断、可纠错、可追溯、可评测的产品体验。
AI Native 前端至少要处理六类问题：
| 问题 | 产品表现 | Harness 视角 |
|---|---|---|
| 流式输出 | 边生成边展示、可停止、可重试 | 需要状态机、Abort、超时、错误恢复 |
| 多轮上下文 | 用户可以追问、修正、补充条件 | 需要会话记忆、上下文选择和压缩 |
| 工具结果展示 | 展示搜索、计算、代码执行、数据查询结果 | 需要工具调用日志、引用来源和结果校验 |
| 结构化输出 | 表格、卡片、步骤、代码 diff、风险列表 | 需要 schema、字段校验和 fallback |
| 可信与安全 | 不编造来源、不渲染危险 HTML、不越权展示数据 | 需要 RAG 引用、权限过滤、安全渲染和人工兜底 |
| 反馈闭环 | 用户点赞、踩、纠错、继续追问 | 需要埋点、评测集、坏例回收和迭代机制 |
这和传统前端的区别很大。传统页面多数是确定性状态机：接口返回什么，页面展示什么；AI Native 页面面对的是不确定输出：模型可能答慢、答偏、答错、格式不稳定、工具失败、上下文过期。前端不能只做"流式打印机"，而要把模型输出产品化。
可以用一个更通用的心智模型描述：
text
用户目标
-> 结构化任务输入
-> 检索业务上下文 / 私有知识 / 工具能力
-> 模型生成中间结果
-> 前端以可解释的交互形态展示
-> 用户纠错或继续追问
-> 工具和指标验证结果
-> 反馈进入评测和 Memory这也是为什么前端工程经验能迁移到 Agent 工程化。前端熟悉用户路径、状态管理、异常兜底、性能体验、埋点监控和权限展示；这些能力正好对应 AI 产品的最后一公里。模型可以生成内容，但用户是否相信、是否能纠错、是否能继续操作、是否能感知风险，很大程度取决于产品和前端工程设计。
从业务层面看，AI 提效也不应该只讲"节省开发时间"。更完整的表达是：AI 可以提升搜索、总结、客服、内容生成、经营建议、数据解释、流程自动化和研发效率，但每个场景都必须回答四个问题：
- 上下文从哪里来：业务数据、知识库、用户输入、日志、代码、历史案例。
- 结果怎么可信：引用来源、结构化输出、规则校验、人工确认。
- 效果怎么衡量：点击率、满意度、转化、处理时长、错误率、人工介入率。
- 风险怎么兜底：权限过滤、敏感内容拦截、回滚、灰度、人工接管。
对前端工程师来说，独特视角在于：理解 Agent 不只要理解模型循环，还要理解 Agent 落到 Web / AI Native 产品后，如何把模型能力变成稳定、可信、可用的用户体验。
一句话总结：
text
Agent Harness 解决"模型如何可靠行动"，AI Native 前端解决"模型行动结果如何被用户理解、信任和继续使用"。前端工程师的机会就在这两者的交界处。9. 最小实操 Demo：半自动 Agent Harness
理解这些机制后，可以用一个最小 Demo 验证是否真的形成了 Harness 闭环。
9.1 Demo 目标
不追求做完整 Agent 平台，而是验证最核心的 Harness 闭环：
text
任务输入
上下文检索
计划生成
工具执行
校验反馈
执行报告
权限和边界意识9.2 目录设计
text
agent-demo/
README.md # Demo 目标、架构、边界
task.md # 输入任务：一个 bugfix 或小需求
context.md # 检索到的上下文
plan.md # 修改计划
report.md # 执行报告
scripts/
search.js # 模拟上下文检索
run-check.js # 模拟验证命令9.3 Demo 流程
text
1. 读取 task.md 作为任务输入。
2. 用 search.js 模拟检索相关文件或文档，输出 context.md。
3. 根据 context.md 生成 plan.md。
4. 人工或脚本模拟执行修改。
5. 运行 run-check.js 做校验。
6. 把执行过程、验证结果、风险和下一步写入 report.md。9.4 对应的 Harness 机制
| Demo 动作 | 对应机制 | 本文位置 |
|---|---|---|
| 任务输入 | Agent Loop 的用户消息 | 2.1 / 5.1 |
| 上下文检索 | Tool Use / Context Engineering | 3 / 5.2 / 6.2 |
| 计划生成 | Todo / Task Planning | 4.3 / 5.3 |
| 工具执行 | Tool Runtime | 4.1 / 5.4 |
| 校验反馈 | Error Recovery / Evaluation | 4.6 / 5.5 |
| 报告输出 | Observation / Human Review | 5.8 / 9.3 |
| 边界说明 | Permission / Safety | 4.2 / 5.7 |
9.5 后续扩展
text
1. 接入真实 LLM API，让模型生成 plan.md。
2. 用 rg / AST 做真实代码检索。
3. 用 MCP Server 接入日志、监控、知识库。
4. 加 permission.json 控制可执行命令。
5. 加 test / lint / typecheck 自动验证。
6. 把成功和失败案例沉淀成 Memory。10. 最终总结
回到 Claude Code 这个观察对象，最值得学的不是它"更会写代码"，而是它把 Agent 从"Prompt + 工作流"推到了"模型 + Harness"。
text
模型负责推理和选择动作。
Harness 负责工具、上下文、权限、评测、记忆、任务、协作、隔离和外部系统接入。一个成熟 Coding Agent 的主循环并不复杂：
text
LLM -> tool_use -> execute -> tool_result -> next round真正复杂的是循环周围的一整套工程机制：
text
工具是否可靠
上下文是否准确
权限是否安全
任务是否收敛
错误是否可恢复
结果是否可验证
经验是否可沉淀
系统是否可扩展这也是前端工程师进入 Agent 工程化最值得抓住的方向：不是只学会让 AI 写代码，而是把过去在工具链、质量体系、性能指标、异常监控和平台化上的经验，迁移到"让模型稳定完成工程任务"的新环境里。