上下文组装
Harness Engineering 先决定哪些文件、规则、历史、语言偏好和外部工具说明进入上下文,而不是把全部资料塞给模型。这是 Harness Engineering 的第一道边界。
Production AI field delivery
深入学习可靠 AI 交付背后的系统与判断:FDE Engineer 如何连接客户发现、Agent Harness、工具、权限、记忆、评测、生产上线和组织采用,并用 AI FDE 现场导师挑战一份真实交付方案。
core model
一个可靠 Agent 不是模型单独完成的。Harness Engineering 把意图、上下文、工具、权限、记忆、执行循环和验证证据拆成工程层;真正的 Harness Engineering 会减少模型猜测,让每一步都能观察、治理和复盘。
Harness Engineering 先决定哪些文件、规则、历史、语言偏好和外部工具说明进入上下文,而不是把全部资料塞给模型。这是 Harness Engineering 的第一道边界。
在 Harness Engineering 里,工具是受治理的产品 API:有输入 schema、输出预算、并发标记、只读标记和失败语义。没有工具契约,就没有稳定的 Harness Engineering。
Harness Engineering 把 allow、ask、deny 和用户可理解的风险解释做成结构化决策,而不是只相信模型会小心。权限层是 Harness Engineering 的信任边界。
Harness Engineering 会让长期规则、项目记忆和领域技能按需加载,避免一次性提示词膨胀,同时保留可追溯来源。好的 Harness Engineering 不把记忆变成传闻。
长任务需要计划、工具调用、流式反馈、压缩、恢复和证据闭环。Harness Engineering 关注的正是这条运行链路,也是 Harness Engineering 区别于单次问答的地方。
source-backed notes
我阅读了 Claude Code 源码中的关键路径,并把可复用的 Harness Engineering 设计点整理成下面六个模块。它们不是抽象口号,而是源码中反复出现的 Harness Engineering 工程边界。
源码把系统提示分成静态段、动态段、memory、环境信息、语言设置、MCP 指令和 cache boundary。Harness Engineering 的重点是让 prompt 成为可缓存、可失效、可解释的上下文管线,这是 Harness Engineering 的核心入口。
Tool 接口包含 call、description、schema、isReadOnly、isConcurrencySafe、isDestructive 和 checkPermissions。Harness Engineering 用这些契约把模型能力变成可审查的执行面,也让 Harness Engineering 能被测试。
权限类型把 default、plan、acceptEdits、dontAsk、bypassPermissions 等模式,与 allow、ask、deny、passthrough 结果分开。Harness Engineering 让授权有理由、有来源、有下一步。
Skills 先用 frontmatter 估算和路由,只有任务匹配时才加载完整说明。Harness Engineering 借此把领域知识做成可发现、可按需展开的能力层。
MCP 配置会计算 server signature、去重插件 server、处理禁用与策略。Harness Engineering 需要先治理外部能力,再把它们暴露给 Agent。
query.ts 在模型调用前应用工具结果预算、snip、microcompact、context collapse 和 autocompact。Harness Engineering 不只要大上下文,还要上下文生命周期。
learning document
Prompt engineering 关注“怎么告诉模型”,Harness Engineering 关注“模型运行在什么系统里”。当 Agent 要处理真实代码库、真实权限、真实部署和多人协作时,单靠提示词无法保证可靠性,所以 Harness Engineering 才会成为 AI 产品的核心能力。
Claude Code 的源码说明,Harness Engineering 会把稳定规则放进静态提示,把会变化的信息放进动态段,把文件读取、编辑、搜索、MCP、Skills 和子任务都放进有契约的工具系统,再用权限层控制风险。
因此,学习 Harness Engineering 的目标不是复刻 Claude Code,而是学会把一个 AI 产品拆成上下文、工具、权限、记忆、循环、验证和 UX。这个拆法能迁移到客服 Agent、数据分析 Agent、内容生产 Agent 和编程 Agent。
从 prompts、Tool、permissions、skills、mcp 和 query 这些文件开始,理解 Harness Engineering 的边界在哪里。
把一次 Agent 对话画成 intent、context、tool、permission、result、compact、verify 的链路。
先实现三个窄工具、一个权限决策对象、一段 memory 加载和一个验证步骤,体验 Harness Engineering 如何减少模型自由度。
不要只看回复是否顺眼,检查工具日志、失败恢复、权限解释、测试结果和用户是否能理解发生了什么。
挑战一份生产 AI 交付方案
你好,我是 AI FDE 现场导师。你可以带来客户问题、技术范围、架构、原型、评测、安全审查、上线计划或采用风险。我会区分事实与假设,让取舍透明,并建议下一项现场成果。
FAQ
这些问题帮助你判断 Harness Engineering 和提示词、Agent 框架、Claude Code 源码学习之间的关系。
Harness Engineering 是围绕模型构建运行环境的工程实践,包括上下文组装、工具契约、权限策略、记忆、状态、编排循环、验证、可观测性和产品 UX。
Prompt engineering 优化模型看到的文字;Harness Engineering 设计模型所在的系统。前者回答“怎么说”,后者回答“怎么让 Agent 在真实世界可靠做事”。学习 Harness Engineering,就是把提示词外面的系统补齐。
Claude Code 是一个真实编程 Agent,它的源码同时展示 prompt 管线、工具系统、权限、MCP、Skills、记忆和长任务压缩,非常适合作为 Harness Engineering 案例。
你可以让导师按 Harness Engineering 视角解释源码文件,比较工具和权限设计,或者把 Claude Code 的设计抽象成你自己的 Agent 产品方案。
只要 Agent 要读写真实系统、调用外部工具、长期记住规则、经过审批或交付可验证结果,团队就需要 Harness Engineering,而不是只维护一份系统提示词。团队级 Harness Engineering 也是产品可靠性的基础。