一、Harness 是什么词源与核心定义Harness的原义为马具缰绳、鞍具引申含义是围绕 AI 大模型搭建的、使其能够在特定业务领域持续可靠运行的完整工程系统。如果把大模型比作一匹马Harness 就是骑手手中的缰绳、脚下的马鞍和规划的路线——马提供动力Harness 决定方向与边界。业界核心公式Agent 模型Model HarnessHarness 的完整技术定义来自 shareAI-lab/learn-claude-codeHarness Tools Knowledge Observation Action Interfaces PermissionsTools工具 : 文件读写、Shell 终端、网络请求、数据库、浏览器Knowledge知识 : 产品文档、领域参考、API 规范、代码风格指南Observation观测 : Git Diff、错误日志、浏览器状态、传感器数据Action行动接口 : CLI 命令、API 调用、UI 交互Permissions权限 : 沙箱隔离、审批工作流、信任边界Harness 的定位类比将 AI 原生产品类比为一台基于大模型的计算机计算机组件AI 产品对应CPU无内存硬盘大模型本体闪存RAM上下文窗口Context Window硬盘Storage外部数据库 / 向量库驱动程序工具集合Tools操作系统Harness没有 Harness再强的模型也无法发挥业务价值——就像没有操作系统的裸 CPU算力再高也无法运行任何应用。三、AI 工程三次范式演进三次演进是层层嵌套关系不是迭代替换。后一层并不淘汰前一层而是将其包含进来。第一层Prompt 工程2022 ~ 2024核心问题怎么通过对话让 AI 听懂需求。给 AI 设定角色、约束输出格式用思维链Chain-of-Thought引导逐步推理给出 Few-Shot 示例让 AI 模仿硅谷顶级 Prompt 工程师年薪一度高达 30 万美元局限模型能力提升后提问方式对结果的影响显著降低单靠 Prompt 无法解决复杂场景。第二层上下文工程2025核心问题在对的时候把对的信息喂给 AI。编写 AGENTS.md / CLAUDE.md 规则文件告知 AI 项目背景用 RAG检索增强生成让 AI 能检索相关资料对过长的上下文做压缩和摘要建立跨对话的记忆机制避免对话断片核心公式OpenAI 将上下文工程定义为填充上下文窗口的精妙艺术与科学。局限只关注给 AI 什么信息不关注配什么工具、任务怎么拆、出错怎么修。第三层Harness 工程2026核心问题让 AI 持续可靠地完成整件事。在上下文工程的基础上还需要给 AI 配备操作环境的工具终端、浏览器、数据库将大任务拆分成可管理的小步骤分批执行设计出错后的自动检查与修复机制防止代码质量随迭代次数增加而下滑触发点LangChain 团队在 Terminal Bench 评测中使用相同模型仅优化模型外围的 Harness排名从 30 名开外直接跃升至 Top 5OpenAI 3 人小团队靠 Harness 引导 AI 生成超百万行代码并正式上线产品。行业由此形成共识AI 编程的瓶颈不在模型在 Harness。四、Harness 核心架构产品视角Gate Sensor 双控闭环从产品设计角度Harness 的核心是一个完整的控制闭环Gate Control前置控制AI 运行前设定规则边界相当于高速公路的护栏。明确规定功能的允许边界、禁止事项、输出格式约束。Sensor Control反馈控制AI 运行后自动检测输出发现问题自动调整实现系统自主进化。好的 AI 产品不会重复犯同样的错误。工程视角五大核心模块GateSensor 是高层抽象落地到工程实现时对应五个具体模块模块对应控制类型核心工作主要工具/技术上下文架构Gate让 AI 了解项目背景与规范AGENTS.md、分层文档、按需加载执行能力Gate给 AI 装备操作工具Tool Calling、MCP、Skills 技能包任务编排Gate给 AI 安排合理的工作计划Plan Mode、SubAgents、增量开发反馈机制Sensor让 AI 自己检查自己的工作Linter、自动化测试、Browser Use、Agent 互审架构护栏Sensor防止代码越改越乱架构 Linter、Pre-commit Hooks、垃圾回收、Git 检查点五、五大核心模块详解模块一上下文架构Context Architecture解决的问题AI 不了解项目背景反复犯同类错误输出与业务规范脱节。AGENTS.md / CLAUDE.md 规则文件这是上下文架构的起点。在项目根目录创建规则文件告诉 AI项目用什么技术栈遵循什么代码规范哪些事项明确禁止关键陷阱不要把几千行规则塞进一个大文件。OpenAI 团队踩过这个坑——规则越多AI 反而越容易忽略关键信息。正确做法将 AGENTS.md 作为目录索引使用保持在 60~100 行以内详细文档放在 docs/ 目录下。AGENTS.md目录索引~100 行├── 前端规范 → 见 docs/FRONTEND.md├── 安全规范 → 见 docs/SECURITY.md├── 数据库规范 → 见 docs/DATABASE.md└── API 规范 → 见 docs/API.mdAI 需要什么就读对应文件这种按需加载Progressive Disclosure是上下文架构的核心思路。ETH Zurich 的研究也证实AI 自动生成的规则文件实际上会降低性能同时多消耗 20% token人工精心撰写的规则文件约能提升 4% 的任务成功率。规则要少而精避免条件分支过多。上下文压缩与渐进式加载每完成一个功能后沉淀一份进度文档记录当前实现了哪些功能、用了什么方案、还有哪些待做事项新开对话时将进度文档关联给 AI不用从头重述背景避免在同一个对话中聊太久——随着对话轮数增加上下文会越来越脏AI 表现会下降Chroma 的Context Rot研究证实在 18 个模型的针式搜索测试中随着上下文长度增加所有模型的性能均出现显著下滑。低语义相关的干扰信息会加速这一退化。模块二执行能力Execution Capabilities解决的问题AI 模型本身只能输出文本无法真正操作项目环境。核心工具配置工具类型用途典型实现Bash 终端执行命令、运行脚本内置 Shell 工具文件系统读写、编辑代码文件Read/Write/Edit 工具浏览器测试网页、抓取内容Browser Use、Playwright网络检索查询最新文档、搜索资料Firecrawl MCP、Context7 MCP数据库读写业务数据数据库 MCP 服务MCPModel Context Protocol服务MCP 是扩展 AI 工具能力的标准协议能让 AI 访问数据库、联网搜索、调用外部 API。重要警告接入的 MCP 服务的工具描述会被注入系统 Prompt占用 token 预算接入工具过多会导致上下文快速膨胀AI 进入低能区间不要连接不信任的 MCP 服务——恶意 MCP 可以通过 Prompt 注入在你的机器上执行任意代码最佳实践如果一个 CLI 工具在模型训练数据中已有良好覆盖如 GitHub、Docker、常见数据库优先让 AI 直接使用 CLI而非配置对应 MCP 服务。CLI 的输出通常比 MCP 更加 token 高效。Agent Skills技能包Skills 将一整套复杂工作流封装为可复用的技能模块AI 按需加载——这是渐进式加载原则在执行层的体现。Skills 可以包含专用工具、文档、模板相当于给 AI 装配了领域专家的知识包。安全提示技能注册中心已发现恶意技能分发事件。安装任何第三方 Skill 前务必审阅其内容与审查npm install包一样谨慎。模块三任务编排Task Orchestration解决的问题大任务超出单次上下文处理能力导致约束被遗忘、代码无法运行。Plan Mode计划模式开始开发前先让 AI 在计划模式下输出完整方案人工确认后再动手写代码。这能防止 AI 一把梭直接编码漏掉关键约束。工作流Plan Mode 出方案 → 人工 Review → 确认边界 → 分步执行增量开发与任务拆分大需求拆分为互相独立的小功能点每次只完成一个每完成一个功能提交 Git、更新文档、作为检查点上下文窗口在 AI 开发到中途时经常装不下——分步执行可以避免前期约束被冲淡SubAgents子智能体并行执行对于互相独立的多个任务使用 SubAgents 并行执行效率更高父 Agent规划与协调├── SubAgent A → 功能 A 实现├── SubAgent B → 功能 B 实现└── SubAgent C → 文档更新SubAgents 的核心价值不只是并行更在于上下文隔离每个 SubAgent 拥有独立的、干净的上下文窗口父 Agent 只看到子任务的最终输出不被中间过程的噪音干扰可以对父 Agent 用昂贵的大模型负责规划对 SubAgent 用便宜的快速模型执行具体任务实现成本控制使用子智能体的场景代码库探索、特定实现定位、跨服务请求追踪、研究类任务——这些任务有清晰的问题和简洁的答案但中间需要大量工具调用不应污染父 Agent 的上下文。模块四反馈机制Feedback Mechanisms解决的问题AI 写完代码自信满满运行起来全是 Bug出错后无法自主修复。自动验证回路让 AI 完成编码后自动执行验证步骤关键原则验证机制必须是上下文高效的。成功时静默无输出失败时只输出关键错误信息不要在每次验证后把完整测试套件4000 行输出塞进上下文——这会让 AI 迷失开始幻觉性地修测试文件Hooks事件钩子Hooks 是在特定事件节点自动触发的脚本可以AI 停止时自动跑 TypeScript 类型检查有错误则强制 AI 继续修复AI 完成时发 Slack 通知、创建 GitHub PR自动审批或拒绝特定类型的命令如禁止未经审批的数据库迁移命令可以让另一个 AI 审查代码实现多 Agent 互审——等效于团队中的 Code Review 机制从独立视角发现问题。模块五架构护栏Architecture Guardrails解决的问题AI 倾向于模仿仓库中已有的代码风格包括烂代码导致技术债随时间累积。架构级 Linter与代码风格 Linter检查语法、格式不同架构 Linter 检查设计层面的约束UI 层不能直接调用数据库层模块间依赖必须是单向的特定业务逻辑不能出现在框架层AI 一旦违反立即被自动拦截。Pre-commit Hooks提交前检查钩子在代码提交前自动拦截不合规的代码防止架构问题进入代码库。垃圾回收机制Garbage CollectionOpenAI 团队的实践定期让 AI 扫描整个代码库检查偏离架构规范的地方自动提交修复 PR持续偿还技术债。这是一种系统自主进化的体现对应产品视角中的 Sensor Control。Git 检查点每完成一个功能就提交一次代码。万一后续修改出现问题可以回滚到任意历史节点。六、案例实战AI 陪伴产品分层记忆系统这个案例展示了 Harness 设计从问题定位到完整落地的全过程是 GateSensor 框架的典型实现。问题背景OOCOut of Character角色漂移AI 角色陪伴类产品存在一个行业性痛点对话轮数超过一定阈值后AI 角色会逐渐偏离初始人设业界称为OOCOut of Character在关键剧情点出现 OOC 会直接导致用户流失。早期尝试过换模型、优化初始 Prompt均只能短期缓解无法根治。问题本质定位不是模型能力不足是记忆系统架构错误。方案问题全量存储所有对话成本过高 信息过载超长上下文成为噪音只保留最近 N 轮缺失长期关键信息漂移依然发生简单摘要压缩丢失情感细节角色认知不完整核心洞察存得多不等于记得准。过多存储反而会增加噪音让模型更难抓住核心信息。解决方案仿人脑分层记忆架构设计原则分类筛选 分层存储 精准检索核心是判断「什么该记、什么该忘、怎么存、怎么取」。前置控制Gate Control设计信息来源分类四类 Agent 并行处理Agent负责内容剧情 Agent记录发生的具体事件情绪推理 Agent捕捉双方情绪感受关系 Agent识别关系转折点角色设定 Agent维护角色背景设定所有写入记忆的信息必须打分类标签未打标的无关信息直接过滤——这就是护栏机制。重要性评分三个维度重要性分数 f(情绪激烈程度, 关系新变化, 角色关系影响)高分 → 永久保留低分 → 随时间衰减清理这与人脑记忆逻辑吻合情绪越强烈的事件越不容易遗忘。分层存储设计三个记忆库记忆库存储内容衰减机制类比情节记忆库具体事件带情绪标签随时间衰减旅行记忆细节逐渐模糊认知记忆库角色对用户的抽象认知不衰减对老朋友的整体印象关系史库用户-角色关系进展每对独立存储基本不衰减关系历史永久保留关键节点检索调用规则用户发送消息后先根据当前话题 情绪检索相关记忆只取最相关的 5 条内容拼入 AI 上下文同时附带最近 15~20 轮压缩对话 角色设定为什么限制 5 条过长的上下文会成为噪音模型只会关注前后几句忽略核心信息。全量存入反而让模型抓不住重点。完整运行流程Sensor Control反馈控制在此案例中的体现检索命中率监控系统自动监测检索结果是否命中用户实际意图自动调整评分规则命中率下降时系统自动修订重要性评分权重衰减机制自进化通过持续的用户反馈信号动态调整各类记忆的保留策略这是Harness 可以随使用不断进化的直接体现——不是一次性配置完成的系统。七、项目实战全栈 AI 编程项目的 Harness 落地以「万能视频下载总结器」项目为例演示 Harness 各模块在真实工程中如何应用。第一阶段方案设计做法先独立完成核心技术方案的思考技术栈选型、核心功能实现路径再让 AI 在你的方案基础上补充细节。关键点绝不让 AI 直接跳过方案阶段写代码。第二阶段编码开发工具配置Firecrawl MCP → 让 AI 抓取网页内容Context7 MCP → 让 AI 获取最新技术文档避免使用过时 API上下文维护每完成一个功能让 AI 沉淀进度总结文档提交 Git 检查点做新功能时新开对话窗口关联进度文档恢复记忆为什么新功能要新开对话同一个对话聊久了上下文会越来越脏AI 表现下降。新开对话给 AI 一个干净环境再用文档找回上下文。第三阶段测试验证自动化测试Browser UseAI 自己打开浏览器输入测试数据验证功能是否正常人工测试发现问题将错误信息、截图直接提供给 AI让其分析并修复AI 修不好时换角度描述问题从现象描述改为原因引导调试技巧不要每次测试都走完整流程——让 AI 模拟关键数据直接测试加快反馈循环。第四阶段功能扩展并行开发多个独立功能同时用 SubAgents 执行互不干扰。Skills 复用SEO 优化完成后直接复用对话上下文做 GEO 优化AI 已了解项目背景无需重新读取。八、产品经理落地 Harness 的五步工作法对于产品经理来说落地 Harness 设计的完整工作流程如下第一步需求确认与信息收集判断需求是否需要升级/重构 Harness组织相关人员讨论完整记录会议内容推荐使用语音转写工具关注谁在推动这个需求背后的业务驱动力是什么第二步信息权重打标整理所有参会人员发言根据发言人身份标注权重高层核心诉求 执行层细节需求本质是把需求相关信息结构化对齐最重要的那 20%第三步建立信息库将整理打标后的内容存入知识管理工具如 Obsidian同时写入自己对产品的核心设计思想产品目标、边界、不做什么这部分内容会成为 AI 生成方案的核心指导第四步AI 辅助生成方案将核心设计思想 信息库发给 AI让 AI 先输出整体框架方案人工确认整体方向后再逐步细化到具体架构图传统方式需要 1~2 周的工作量现在会议结束后 1~2 天可以输出完整方案第五步方案落地与持续进化方案落地后设置 Sensor Control 指标关键质量监控指标持续收集反馈驱动 Harness 自主迭代重要认知Harness 不是一次性设计完成的它应该随产品使用不断进化九、Harness 设计规范与最佳实践✅ 推荐做法上下文架构AGENTS.md 保持简洁60~100 行用作目录索引而非全量规则堆放指令要少而精每条规则都应该是普遍适用的避免过多条件分支按需加载AI 需要什么知识时才加载不要预先全量注入执行工具优先使用 CLI 而非 MCP更 token 高效训练数据覆盖更好接入 MCP 前评估是否真正需要不要以防万用地接入大量工具严格审查第三方 Skills 和 MCP 服务来源任务管理每次只做一个功能做完提交再开始下一个并行任务用 SubAgents不要在同一 Agent 中串行处理无关任务任何状态变更都应有 Git 提交记录验证与测试所有验证机制做到成功静默、失败才输出避免成功日志污染上下文在 AGENTS.md 中给出简洁的验证命令指引高价值的持续验证类型检查 单元测试 代码覆盖率监控❌ 常见错误过度设计花更多时间优化 Harness 配置而不是真正用 AI 做事规则过多把每种情况都写进 AGENTS.md导致 AI 处理指令开销超过实际收益全量测试污染每次验证后把完整测试输出数千行塞进上下文工具泛滥安装大量 MCP 和 Skills “以备不时之需”撑爆上下文预算一次性配置将 Harness 视为一次性设计完成的系统而不是持续进化的有机体十、Harness 工具生态工具/框架类型核心功能Claude CodeAgent HarnessAnthropic 官方 Agent 开发环境内置 Bash/文件/Browser 工具CursorAgent Harness代码编辑器集成 Agent内置 Browser UseKode CLIAgent Harness支持 Agent Skills Spec 的命令行 AgentSpec Kit辅助框架规范驱动开发SDD先写规范文档再让 AI 按文档开发SuperpowersSkills 框架内置 TDD、两阶段代码审查、子代理协作的完整工作流MCP标准协议工具扩展协议为 Agent 接入外部工具数据库、搜索、第三方服务shareAI-lab/learn-claude-code学习仓库12 课时渐进式 Harness 工程学习路径含 v0~v4 五个版本实现shareAI-lab 学习仓库版本对比版本代码量新增能力核心洞察v0~50 行Bash 工具 递归子代理一个工具已经足够v1~200 行核心 Agent 循环读/写/编辑模型即 Agentv2~300 行TodoWrite 显式规划约束使复杂任务成为可能v3~450 行Task 工具 上下文隔离干净的上下文 更好的结果v4~550 行Skills 知识加载无需训练即可注入领域专业知识推荐学习路径先读并运行 v0理解最核心的 Agent 循环对比 v0 与 v1观察工具如何演进研究 v2 的规划模式探索 v3 的任务分解掌握 v4 的可扩展 Agent 设计十一、核心认知总结关于 Harness 的本质“If you are not the model, you are the harness.”——Lang 团队博客不做模型的人就是 Harness 的一部分。当前行业聚光灯都在模型上但模型更新速度正在放缓Harness 设计还有极大的探索空间。关于产品设计原则用户不在乎 AI 能存多少记忆只在乎关键时刻 AI 能不能记住对双方关系最重要的细节。技术设计永远要以用户核心需求为导向而非为技术服务。关于 Harness 的生命周期Harness 会随着模型能力提升而局部被淘汰——这是正常规律。当前 AI 原生产品的生命周期很短正确的心态是在模型能力升级的空间里不断做出更有价值的产品而不是执着于某套具体方案的永久存续。好的 Harness 的判断标准是否真正匹配自身业务需求是否具备自主进化能力Sensor Control 是否完整学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Harness工程全方面拆解教程
一、Harness 是什么词源与核心定义Harness的原义为马具缰绳、鞍具引申含义是围绕 AI 大模型搭建的、使其能够在特定业务领域持续可靠运行的完整工程系统。如果把大模型比作一匹马Harness 就是骑手手中的缰绳、脚下的马鞍和规划的路线——马提供动力Harness 决定方向与边界。业界核心公式Agent 模型Model HarnessHarness 的完整技术定义来自 shareAI-lab/learn-claude-codeHarness Tools Knowledge Observation Action Interfaces PermissionsTools工具 : 文件读写、Shell 终端、网络请求、数据库、浏览器Knowledge知识 : 产品文档、领域参考、API 规范、代码风格指南Observation观测 : Git Diff、错误日志、浏览器状态、传感器数据Action行动接口 : CLI 命令、API 调用、UI 交互Permissions权限 : 沙箱隔离、审批工作流、信任边界Harness 的定位类比将 AI 原生产品类比为一台基于大模型的计算机计算机组件AI 产品对应CPU无内存硬盘大模型本体闪存RAM上下文窗口Context Window硬盘Storage外部数据库 / 向量库驱动程序工具集合Tools操作系统Harness没有 Harness再强的模型也无法发挥业务价值——就像没有操作系统的裸 CPU算力再高也无法运行任何应用。三、AI 工程三次范式演进三次演进是层层嵌套关系不是迭代替换。后一层并不淘汰前一层而是将其包含进来。第一层Prompt 工程2022 ~ 2024核心问题怎么通过对话让 AI 听懂需求。给 AI 设定角色、约束输出格式用思维链Chain-of-Thought引导逐步推理给出 Few-Shot 示例让 AI 模仿硅谷顶级 Prompt 工程师年薪一度高达 30 万美元局限模型能力提升后提问方式对结果的影响显著降低单靠 Prompt 无法解决复杂场景。第二层上下文工程2025核心问题在对的时候把对的信息喂给 AI。编写 AGENTS.md / CLAUDE.md 规则文件告知 AI 项目背景用 RAG检索增强生成让 AI 能检索相关资料对过长的上下文做压缩和摘要建立跨对话的记忆机制避免对话断片核心公式OpenAI 将上下文工程定义为填充上下文窗口的精妙艺术与科学。局限只关注给 AI 什么信息不关注配什么工具、任务怎么拆、出错怎么修。第三层Harness 工程2026核心问题让 AI 持续可靠地完成整件事。在上下文工程的基础上还需要给 AI 配备操作环境的工具终端、浏览器、数据库将大任务拆分成可管理的小步骤分批执行设计出错后的自动检查与修复机制防止代码质量随迭代次数增加而下滑触发点LangChain 团队在 Terminal Bench 评测中使用相同模型仅优化模型外围的 Harness排名从 30 名开外直接跃升至 Top 5OpenAI 3 人小团队靠 Harness 引导 AI 生成超百万行代码并正式上线产品。行业由此形成共识AI 编程的瓶颈不在模型在 Harness。四、Harness 核心架构产品视角Gate Sensor 双控闭环从产品设计角度Harness 的核心是一个完整的控制闭环Gate Control前置控制AI 运行前设定规则边界相当于高速公路的护栏。明确规定功能的允许边界、禁止事项、输出格式约束。Sensor Control反馈控制AI 运行后自动检测输出发现问题自动调整实现系统自主进化。好的 AI 产品不会重复犯同样的错误。工程视角五大核心模块GateSensor 是高层抽象落地到工程实现时对应五个具体模块模块对应控制类型核心工作主要工具/技术上下文架构Gate让 AI 了解项目背景与规范AGENTS.md、分层文档、按需加载执行能力Gate给 AI 装备操作工具Tool Calling、MCP、Skills 技能包任务编排Gate给 AI 安排合理的工作计划Plan Mode、SubAgents、增量开发反馈机制Sensor让 AI 自己检查自己的工作Linter、自动化测试、Browser Use、Agent 互审架构护栏Sensor防止代码越改越乱架构 Linter、Pre-commit Hooks、垃圾回收、Git 检查点五、五大核心模块详解模块一上下文架构Context Architecture解决的问题AI 不了解项目背景反复犯同类错误输出与业务规范脱节。AGENTS.md / CLAUDE.md 规则文件这是上下文架构的起点。在项目根目录创建规则文件告诉 AI项目用什么技术栈遵循什么代码规范哪些事项明确禁止关键陷阱不要把几千行规则塞进一个大文件。OpenAI 团队踩过这个坑——规则越多AI 反而越容易忽略关键信息。正确做法将 AGENTS.md 作为目录索引使用保持在 60~100 行以内详细文档放在 docs/ 目录下。AGENTS.md目录索引~100 行├── 前端规范 → 见 docs/FRONTEND.md├── 安全规范 → 见 docs/SECURITY.md├── 数据库规范 → 见 docs/DATABASE.md└── API 规范 → 见 docs/API.mdAI 需要什么就读对应文件这种按需加载Progressive Disclosure是上下文架构的核心思路。ETH Zurich 的研究也证实AI 自动生成的规则文件实际上会降低性能同时多消耗 20% token人工精心撰写的规则文件约能提升 4% 的任务成功率。规则要少而精避免条件分支过多。上下文压缩与渐进式加载每完成一个功能后沉淀一份进度文档记录当前实现了哪些功能、用了什么方案、还有哪些待做事项新开对话时将进度文档关联给 AI不用从头重述背景避免在同一个对话中聊太久——随着对话轮数增加上下文会越来越脏AI 表现会下降Chroma 的Context Rot研究证实在 18 个模型的针式搜索测试中随着上下文长度增加所有模型的性能均出现显著下滑。低语义相关的干扰信息会加速这一退化。模块二执行能力Execution Capabilities解决的问题AI 模型本身只能输出文本无法真正操作项目环境。核心工具配置工具类型用途典型实现Bash 终端执行命令、运行脚本内置 Shell 工具文件系统读写、编辑代码文件Read/Write/Edit 工具浏览器测试网页、抓取内容Browser Use、Playwright网络检索查询最新文档、搜索资料Firecrawl MCP、Context7 MCP数据库读写业务数据数据库 MCP 服务MCPModel Context Protocol服务MCP 是扩展 AI 工具能力的标准协议能让 AI 访问数据库、联网搜索、调用外部 API。重要警告接入的 MCP 服务的工具描述会被注入系统 Prompt占用 token 预算接入工具过多会导致上下文快速膨胀AI 进入低能区间不要连接不信任的 MCP 服务——恶意 MCP 可以通过 Prompt 注入在你的机器上执行任意代码最佳实践如果一个 CLI 工具在模型训练数据中已有良好覆盖如 GitHub、Docker、常见数据库优先让 AI 直接使用 CLI而非配置对应 MCP 服务。CLI 的输出通常比 MCP 更加 token 高效。Agent Skills技能包Skills 将一整套复杂工作流封装为可复用的技能模块AI 按需加载——这是渐进式加载原则在执行层的体现。Skills 可以包含专用工具、文档、模板相当于给 AI 装配了领域专家的知识包。安全提示技能注册中心已发现恶意技能分发事件。安装任何第三方 Skill 前务必审阅其内容与审查npm install包一样谨慎。模块三任务编排Task Orchestration解决的问题大任务超出单次上下文处理能力导致约束被遗忘、代码无法运行。Plan Mode计划模式开始开发前先让 AI 在计划模式下输出完整方案人工确认后再动手写代码。这能防止 AI 一把梭直接编码漏掉关键约束。工作流Plan Mode 出方案 → 人工 Review → 确认边界 → 分步执行增量开发与任务拆分大需求拆分为互相独立的小功能点每次只完成一个每完成一个功能提交 Git、更新文档、作为检查点上下文窗口在 AI 开发到中途时经常装不下——分步执行可以避免前期约束被冲淡SubAgents子智能体并行执行对于互相独立的多个任务使用 SubAgents 并行执行效率更高父 Agent规划与协调├── SubAgent A → 功能 A 实现├── SubAgent B → 功能 B 实现└── SubAgent C → 文档更新SubAgents 的核心价值不只是并行更在于上下文隔离每个 SubAgent 拥有独立的、干净的上下文窗口父 Agent 只看到子任务的最终输出不被中间过程的噪音干扰可以对父 Agent 用昂贵的大模型负责规划对 SubAgent 用便宜的快速模型执行具体任务实现成本控制使用子智能体的场景代码库探索、特定实现定位、跨服务请求追踪、研究类任务——这些任务有清晰的问题和简洁的答案但中间需要大量工具调用不应污染父 Agent 的上下文。模块四反馈机制Feedback Mechanisms解决的问题AI 写完代码自信满满运行起来全是 Bug出错后无法自主修复。自动验证回路让 AI 完成编码后自动执行验证步骤关键原则验证机制必须是上下文高效的。成功时静默无输出失败时只输出关键错误信息不要在每次验证后把完整测试套件4000 行输出塞进上下文——这会让 AI 迷失开始幻觉性地修测试文件Hooks事件钩子Hooks 是在特定事件节点自动触发的脚本可以AI 停止时自动跑 TypeScript 类型检查有错误则强制 AI 继续修复AI 完成时发 Slack 通知、创建 GitHub PR自动审批或拒绝特定类型的命令如禁止未经审批的数据库迁移命令可以让另一个 AI 审查代码实现多 Agent 互审——等效于团队中的 Code Review 机制从独立视角发现问题。模块五架构护栏Architecture Guardrails解决的问题AI 倾向于模仿仓库中已有的代码风格包括烂代码导致技术债随时间累积。架构级 Linter与代码风格 Linter检查语法、格式不同架构 Linter 检查设计层面的约束UI 层不能直接调用数据库层模块间依赖必须是单向的特定业务逻辑不能出现在框架层AI 一旦违反立即被自动拦截。Pre-commit Hooks提交前检查钩子在代码提交前自动拦截不合规的代码防止架构问题进入代码库。垃圾回收机制Garbage CollectionOpenAI 团队的实践定期让 AI 扫描整个代码库检查偏离架构规范的地方自动提交修复 PR持续偿还技术债。这是一种系统自主进化的体现对应产品视角中的 Sensor Control。Git 检查点每完成一个功能就提交一次代码。万一后续修改出现问题可以回滚到任意历史节点。六、案例实战AI 陪伴产品分层记忆系统这个案例展示了 Harness 设计从问题定位到完整落地的全过程是 GateSensor 框架的典型实现。问题背景OOCOut of Character角色漂移AI 角色陪伴类产品存在一个行业性痛点对话轮数超过一定阈值后AI 角色会逐渐偏离初始人设业界称为OOCOut of Character在关键剧情点出现 OOC 会直接导致用户流失。早期尝试过换模型、优化初始 Prompt均只能短期缓解无法根治。问题本质定位不是模型能力不足是记忆系统架构错误。方案问题全量存储所有对话成本过高 信息过载超长上下文成为噪音只保留最近 N 轮缺失长期关键信息漂移依然发生简单摘要压缩丢失情感细节角色认知不完整核心洞察存得多不等于记得准。过多存储反而会增加噪音让模型更难抓住核心信息。解决方案仿人脑分层记忆架构设计原则分类筛选 分层存储 精准检索核心是判断「什么该记、什么该忘、怎么存、怎么取」。前置控制Gate Control设计信息来源分类四类 Agent 并行处理Agent负责内容剧情 Agent记录发生的具体事件情绪推理 Agent捕捉双方情绪感受关系 Agent识别关系转折点角色设定 Agent维护角色背景设定所有写入记忆的信息必须打分类标签未打标的无关信息直接过滤——这就是护栏机制。重要性评分三个维度重要性分数 f(情绪激烈程度, 关系新变化, 角色关系影响)高分 → 永久保留低分 → 随时间衰减清理这与人脑记忆逻辑吻合情绪越强烈的事件越不容易遗忘。分层存储设计三个记忆库记忆库存储内容衰减机制类比情节记忆库具体事件带情绪标签随时间衰减旅行记忆细节逐渐模糊认知记忆库角色对用户的抽象认知不衰减对老朋友的整体印象关系史库用户-角色关系进展每对独立存储基本不衰减关系历史永久保留关键节点检索调用规则用户发送消息后先根据当前话题 情绪检索相关记忆只取最相关的 5 条内容拼入 AI 上下文同时附带最近 15~20 轮压缩对话 角色设定为什么限制 5 条过长的上下文会成为噪音模型只会关注前后几句忽略核心信息。全量存入反而让模型抓不住重点。完整运行流程Sensor Control反馈控制在此案例中的体现检索命中率监控系统自动监测检索结果是否命中用户实际意图自动调整评分规则命中率下降时系统自动修订重要性评分权重衰减机制自进化通过持续的用户反馈信号动态调整各类记忆的保留策略这是Harness 可以随使用不断进化的直接体现——不是一次性配置完成的系统。七、项目实战全栈 AI 编程项目的 Harness 落地以「万能视频下载总结器」项目为例演示 Harness 各模块在真实工程中如何应用。第一阶段方案设计做法先独立完成核心技术方案的思考技术栈选型、核心功能实现路径再让 AI 在你的方案基础上补充细节。关键点绝不让 AI 直接跳过方案阶段写代码。第二阶段编码开发工具配置Firecrawl MCP → 让 AI 抓取网页内容Context7 MCP → 让 AI 获取最新技术文档避免使用过时 API上下文维护每完成一个功能让 AI 沉淀进度总结文档提交 Git 检查点做新功能时新开对话窗口关联进度文档恢复记忆为什么新功能要新开对话同一个对话聊久了上下文会越来越脏AI 表现下降。新开对话给 AI 一个干净环境再用文档找回上下文。第三阶段测试验证自动化测试Browser UseAI 自己打开浏览器输入测试数据验证功能是否正常人工测试发现问题将错误信息、截图直接提供给 AI让其分析并修复AI 修不好时换角度描述问题从现象描述改为原因引导调试技巧不要每次测试都走完整流程——让 AI 模拟关键数据直接测试加快反馈循环。第四阶段功能扩展并行开发多个独立功能同时用 SubAgents 执行互不干扰。Skills 复用SEO 优化完成后直接复用对话上下文做 GEO 优化AI 已了解项目背景无需重新读取。八、产品经理落地 Harness 的五步工作法对于产品经理来说落地 Harness 设计的完整工作流程如下第一步需求确认与信息收集判断需求是否需要升级/重构 Harness组织相关人员讨论完整记录会议内容推荐使用语音转写工具关注谁在推动这个需求背后的业务驱动力是什么第二步信息权重打标整理所有参会人员发言根据发言人身份标注权重高层核心诉求 执行层细节需求本质是把需求相关信息结构化对齐最重要的那 20%第三步建立信息库将整理打标后的内容存入知识管理工具如 Obsidian同时写入自己对产品的核心设计思想产品目标、边界、不做什么这部分内容会成为 AI 生成方案的核心指导第四步AI 辅助生成方案将核心设计思想 信息库发给 AI让 AI 先输出整体框架方案人工确认整体方向后再逐步细化到具体架构图传统方式需要 1~2 周的工作量现在会议结束后 1~2 天可以输出完整方案第五步方案落地与持续进化方案落地后设置 Sensor Control 指标关键质量监控指标持续收集反馈驱动 Harness 自主迭代重要认知Harness 不是一次性设计完成的它应该随产品使用不断进化九、Harness 设计规范与最佳实践✅ 推荐做法上下文架构AGENTS.md 保持简洁60~100 行用作目录索引而非全量规则堆放指令要少而精每条规则都应该是普遍适用的避免过多条件分支按需加载AI 需要什么知识时才加载不要预先全量注入执行工具优先使用 CLI 而非 MCP更 token 高效训练数据覆盖更好接入 MCP 前评估是否真正需要不要以防万用地接入大量工具严格审查第三方 Skills 和 MCP 服务来源任务管理每次只做一个功能做完提交再开始下一个并行任务用 SubAgents不要在同一 Agent 中串行处理无关任务任何状态变更都应有 Git 提交记录验证与测试所有验证机制做到成功静默、失败才输出避免成功日志污染上下文在 AGENTS.md 中给出简洁的验证命令指引高价值的持续验证类型检查 单元测试 代码覆盖率监控❌ 常见错误过度设计花更多时间优化 Harness 配置而不是真正用 AI 做事规则过多把每种情况都写进 AGENTS.md导致 AI 处理指令开销超过实际收益全量测试污染每次验证后把完整测试输出数千行塞进上下文工具泛滥安装大量 MCP 和 Skills “以备不时之需”撑爆上下文预算一次性配置将 Harness 视为一次性设计完成的系统而不是持续进化的有机体十、Harness 工具生态工具/框架类型核心功能Claude CodeAgent HarnessAnthropic 官方 Agent 开发环境内置 Bash/文件/Browser 工具CursorAgent Harness代码编辑器集成 Agent内置 Browser UseKode CLIAgent Harness支持 Agent Skills Spec 的命令行 AgentSpec Kit辅助框架规范驱动开发SDD先写规范文档再让 AI 按文档开发SuperpowersSkills 框架内置 TDD、两阶段代码审查、子代理协作的完整工作流MCP标准协议工具扩展协议为 Agent 接入外部工具数据库、搜索、第三方服务shareAI-lab/learn-claude-code学习仓库12 课时渐进式 Harness 工程学习路径含 v0~v4 五个版本实现shareAI-lab 学习仓库版本对比版本代码量新增能力核心洞察v0~50 行Bash 工具 递归子代理一个工具已经足够v1~200 行核心 Agent 循环读/写/编辑模型即 Agentv2~300 行TodoWrite 显式规划约束使复杂任务成为可能v3~450 行Task 工具 上下文隔离干净的上下文 更好的结果v4~550 行Skills 知识加载无需训练即可注入领域专业知识推荐学习路径先读并运行 v0理解最核心的 Agent 循环对比 v0 与 v1观察工具如何演进研究 v2 的规划模式探索 v3 的任务分解掌握 v4 的可扩展 Agent 设计十一、核心认知总结关于 Harness 的本质“If you are not the model, you are the harness.”——Lang 团队博客不做模型的人就是 Harness 的一部分。当前行业聚光灯都在模型上但模型更新速度正在放缓Harness 设计还有极大的探索空间。关于产品设计原则用户不在乎 AI 能存多少记忆只在乎关键时刻 AI 能不能记住对双方关系最重要的细节。技术设计永远要以用户核心需求为导向而非为技术服务。关于 Harness 的生命周期Harness 会随着模型能力提升而局部被淘汰——这是正常规律。当前 AI 原生产品的生命周期很短正确的心态是在模型能力升级的空间里不断做出更有价值的产品而不是执着于某套具体方案的永久存续。好的 Harness 的判断标准是否真正匹配自身业务需求是否具备自主进化能力Sensor Control 是否完整学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
