agent 是智能体的意思，什么是智能体呢，为啥不叫AI了啊，也不叫大模型了，其实这并不是孤立的概念，AI中文就是人工智能，英文全称：Artificial Intelligence，其实就是计算机科学的一个分支，用来研究开发模拟，延伸人的理论方法技术和应用研究。大模型是ai具象化的技术产品，大模型还分了LLM语言大模型、VLM视觉大模型、MLLM多模态、技术上又出现了很多细节，比如混合专家模型-MOE。 MCP 是定的ai识别的上下文协议，用来，调用外部的服务器，返回固定内容信息的一个规则，大家都用这个规则，不就方便了ai调用外部工具获取信息了。方便打通不同企业数据库和ai的交互。 tools 就是工具的意思，这里和mcp紧密相连，tools泛指一类工具，遵循的上下文协议也未必是mcp。方便ai通过这个工具进行获取信息。 plugin是插件的意思，就是个扩展包，这不是ai独有的概念，浏览器有插件，任何应用都可能有插件，一个插件里面东西就多了，可以包含skill，agents，hooks，mcp severs等内容。 prompt是提示词的意思，大模型学的东西多了，大模型要在知识汪洋中预测你想要的下一个词，简直不要太难，那么就帮她缩小范围降低幻觉，那就是定人物，定任务范围，定目标，这样将结合以上的信息，进行数据处理，就大大降低了，大模型胡说八道的可能性。大模型本身就是个统计学问题，根本不具备任何智慧，和反思能力，并非动态进化的，而是提前通过人类社会无数的现有文档，向量化，然后通过多维向量的训练出来的，一个具备无数维度的数学矩阵，通过通过上下文的切割成token又称词元，一个词元就是一个数字，多个词元就组成了一个数学矩阵，将这个数学矩阵扔到transform架构的数学矩阵中。我也不知道是不是百亿参数是不是也决定了词元的数量呢，会影响回应呢？ workflow就是工作流，针对一项工作设计的工作流程，使其完成特定的任务，取代繁重的工作。 hook钩子的意思，什么是钩子啊就是，当执行到特定情况或者涉及特殊判断的时候就会触发的程序，相当于一个钩子，勾住了你的工作流，在特定情况下触发，进而保证进程的稳定和顺利。 skill技能的意思，技能可以是一个md说明的工作文档，也可以是md说明文档加一些小程序、或者一些模板的综合体，目标就是让大模型能按你的md说明文档进行工作。 harness就是一个工作台，工作台上啥也有，自由搭配，想用啥就用啥，比如有plugin、tools、prompt、workflow、hook、skill、和设定好的agent。 AI / 人工智能 └── 大模型 / LLM / VLM / MLLM └── Agentic System / 智能体系统 ├── Prompt：给模型的指令 ├── Context：当前任务上下文 ├── Memory：可长期保存或检索的历史信息 ├── Tools：模型可调用的外部能力 │ └── MCP：连接 tools / resources / prompts 的标准协议之一 ├── Workflow：预设流程 ├── Hook：生命周期触发器 ├── Skill：可复用能力包 ├── Plugin：可安装扩展包 └── Harness：运行框架 / 执行外壳 agent 是配置了 instructions、tools，以及可选运行行为的 LLM MCP Server 可以向 AI 应用暴露 resources、prompts 和 tools。这样不同 AI 应用和不同外部系统之间就不用每次都重新写一套私有接口。 Tool：一个具体能力 MCP Tool：通过 MCP 协议暴露出来的 tool MCP Server：把一组 tools / resources / prompts 提供给 AI 应用 Agent：根据任务需要决定是否调用这些工具 plugin 可能包含 tools、skills、agents、hooks、MCP servers 等内容。简单说，plugin 是“打包和分发能力”的方式。 prompt 帮模型缩小范围，降低幻觉。这个是对的。OpenAI 文档也把 prompt engineering 描述为编写有效指令，让模型更稳定地产生符合要求的内容。 大模型本质上是通过大量数据训练出来的神经网络，它没有人类意义上的主观意识，也不会在普通对话中自动修改自己的模型参数。它的回答来自当前输入、上下文、训练得到的参数，以及推理时的生成过程。我们看到的“推理”“反思”“自我检查”，更多是模型在特定提示、上下文或工具流程下表现出来的能力，而不是人类式的自我意识。 Token：文本被切分后的处理单位。 Token ID：token 被映射成的数字编号。 Embedding：token ID 进入模型后对应的向量表示。 Parameter：模型训练出来的权重和偏置。 Context window：一次输入/输出能处理的 token 上限。 Training tokens：训练时看过的数据 token 数量。 Vocabulary size：分词器支持的 token 种类数量。 文本会先被 tokenizer 切成 token，再映射成 token ID。模型会把 token ID 转成向量表示，也就是 embedding，然后送入 Transformer 网络中计算。Transformer 通过注意力机制和多层神经网络，结合上下文预测后续 token。参数量指的是模型内部训练出来的权重数量，和输入 token 数不是同一个概念。 Workflow 是预先设计好的流程。它强调“步骤固定、路径清楚、可控性强”。比如先读订单，再判断退款规则，再调用退款接口，再发送通知。workflow 里可以用大模型，也可以不用大模型。它和 agent 的区别是：workflow 的路径主要由人或程序提前写好；agent 的路径更多由模型根据目标和中间结果动态决定。 Anthropic 对这个区别说得很清楚：workflows 是 LLM 和工具通过预定义代码路径编排；agents 则是 LLM 动态决定自己的流程和工具使用。 这个方向对。Anthropic 的 Agent Skills 文档也把 skill 描述为模块化能力包，包含 instructions、metadata 和可选资源，比如 scripts、templates，Claude 会在相关任务中自动使用。 另一个官方指南也说 Skills 可以是由 instructions、scripts、resources 组成的文件夹 Context：这次对话/这次任务临时放进来的信息。 Memory：跨会话保存、以后还能拿出来用的信息。 Context 是模型当前这次任务能看到的信息，比如用户问题、系统指令、聊天历史、检索到的文档、工具返回结果等。Memory 是被长期保存、之后还能被取出来的信息，比如用户偏好、项目背景、历史决策、常用规则等。Memory 不是模型参数本身发生了变化，而是系统把相关历史信息保存下来，在需要时重新塞回 context。 5 个帖子 - 4 位参与者 阅读完整话题
GitHub - affaan-m/ECC: The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond. · GitHub 这个项目有大佬真实使用吗？效果怎么样？最终任务实现效果怎么样？费 token 不？ 2 个帖子 - 2 位参与者 阅读完整话题
CC已经"被开源"这么久了，harness的概念也火了好久了，像Trae和Qoder之流现在是否到达能用的水平了？ 2 个帖子 - 2 位参与者 阅读完整话题
昨天刷 X 发现一个推文，有的人使用 claude code /codex + harness + Hermes 一起用，这是个什么思路啊（主要是现在找不到哪个帖子了），这样使用有什么优缺点？ 3 个帖子 - 3 位参与者 阅读完整话题
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
生活所迫！猫猫不易！说好的不聊harness的，这里小反悔一下，再次来聊一次harness。 最近在公司本来做AI应用做得好好的，而且也带着同事搞AI编程搞得飞起，最近合计一下数据，编程效率提升50-60%，然后就被领导高层注意到了，然后我就被抓住了。 副总：你过来帮我做我的这个项目 研发总监：虽然我很舍不得你，不过别人是二把手，我也留不住你。 我一下子从公司的AI应用独立研发，变成了让我去从0带一个研发团队转型AI编程，我真尼玛炸了，带研发转型AI编程，第一步很容易，无非就是教会他们熟练使用claude code，第二步很难，要教他们如何写提示词，这一步，难如登天。大家都知道，vibe coding的质量与效率取决于提示词写得怎么样。目前带这个团队已经两周了，虽然效率有一定提升，但是真的不明显，再不想点招，可能年底要挨刀了。 上面是原因之一，另一个原因是最近在站内总是刷到应该如何进行vibe coding的问答贴 最后一个原因就是原先做的harness，都是从0开始的新项目最适用，如果维护老项目的话，还是会回退到vibe coding，就像如今的我，回退到维护老项目。 这里叠个甲，我个人认为superpower、oh-my-xxxx等类似这类的框架对于claude code都太重，且没有太多的使用价值，所以就不在本文的讨论范围了。 综上，我打算再起一个harness，本次harness完全针对vibe coding，有以下三大目标： vibe coding时，并非只使用claude 模型，所以尽量做到提示词适配模型 以CLAUDE.md为基础文件，提示词推进，接受模型优化反馈，做到本地自迭代vide coding效益 始终让claude code或模型保持质量自检，人工复核 基于以上目标，设计了以下架构，先画个图，来听取一下各位的建议 3 个帖子 - 2 位参与者 阅读完整话题
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
最开始写了一个 tui 简陋版本 然后 cc 的源码泄漏 看了下 cc 的代码 又迭代了一个版本 拆出来了 core 和 tui 。cc 的 tui 和 core 还是太耦合了 这个时候 core 我就单独发了一个包 写在实际项目里 读取线上 bad case. 然后做自迭代。 后面用起来实在不得劲 又加了一个 electron 版本。 兼容了一下 cc 和 codex 的 plugin 。 刚才准备更一个 plugin 来用 突然发现又一点 surprise 。 因为想给几个好朋友内测一下。之前又个前端朋友给 tui 用的时候 feedback 不能选 element 让 ai 改样式不好用 准备做几个插件出来。 https://litter.catbox.moe/yt5n67.png https://litter.catbox.moe/19tbf0.png https://litter.catbox.moe/1zxal1.png 因为我的思路还是以前做圈选 选 element 的思路 然后发现 element 已经 out 了 直接也买呢选个框就行 内容什么的 element 自己底层拿到就好 配合一个多摸态 模型的话 应该样式 重叠 element 能改的更好了 https://github.com/cjhyy/codeshell 欢迎大家试用一下 还没有发 release 版本 想用的自己 bun run dev 一下
Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。 所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。 它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。 这次最关键的变化，是加了一层 workflow-plan.json 。 过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。 现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。 这个拆分很重要。 因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。 我现在会把 Harness 分成几层看 第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。 第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。 第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。 第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。 第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。 关于 SKILL.md 的瘦身 另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。 现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。
Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。 所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。 它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。 这次最关键的变化，是加了一层 workflow-plan.json 。 过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。 现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。 这个拆分很重要。 因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。 我现在会把 Harness 分成几层看 第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。 第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。 第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。 第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。 第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。 关于 SKILL.md 的瘦身 另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。 现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。
Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。 所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。 它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。 这次最关键的变化，是加了一层 workflow-plan.json 。 过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。 现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。 这个拆分很重要。 因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。 我现在会把 Harness 分成几层看 第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。 第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。 第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。 第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。 第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。 关于 SKILL.md 的瘦身 另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。 现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。
Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。 所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。 它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。 这次最关键的变化，是加了一层 workflow-plan.json 。 过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。 现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。 这个拆分很重要。 因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。 我现在会把 Harness 分成几层看 第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。 第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。 第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。 第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。 第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。 关于 SKILL.md 的瘦身 另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。 现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。
Harness 不是让 Agent 更聪明，而是让 Agent 的工作更可信。 所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。 它要管五件事：流程怎么定义，当前跑到哪，产物以什么为准，什么时候允许继续，失败后怎么恢复。 这次最关键的变化，是加了一层 workflow-plan.json 。 过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物"，runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。 现在初始化时，会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ，以及这些节点之间的依赖关系。与此同时，workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么"，runId 描述的是"这一次具体执行"。 这个拆分很重要。 因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存；运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起，很多恢复逻辑只能靠约定。现在它们开始有了明确边界。 我现在会把 Harness 分成几层看 第一层是定义层。 它回答：这条流水线到底是什么？比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。 第二层是运行层。 它回答：这一次跑到哪了？这里靠的是事件流和 execution.json ，而不是聊天上下文。聊天记录不可靠，事件流才是状态真相源。 第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告，这些落盘并被 runtime 记录后，才算正式产物。Agent 说自己完成了，不等于完成了。 第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ，本质上都是在问同一个问题：凭什么继续？这层是防止"看起来完成了"的关键。 第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技，而是让中断之后不用靠人脑捡现场，也不用全量重跑。 关于 SKILL.md 的瘦身 另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ，什么都写在里面。这样越复杂，越依赖模型一次性记住，最后又回到"让模型自己记流程"的老路。 现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ，都拆到 references 里按需读取。
论文： [2605.27922] Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows 代码： GitHub - Qihoo360/harness-bench · GitHub harness-bench.ai Leaderboard - Harness Bench Harness Bench leaderboard across harnesses, models, domains, and completion, process, and combined task scores. harness bench 简单来说就是固定任务和模型，只换harness，看agent表现差多少。 方法 106个沙箱化离线任务，8个类别（SWE、数据分析、DevOps、长程状态维护等），每个任务有独立的oracle grader。 评估维度有completion score 、LLM judge score 和security score。 测了6个现在比较火的agent（OpenClaw、nanobot、Hermes、ZeroClaw、NullClaw、Moltis） 8个模型后端（gpt-5.4、claude-opus-4.6、claude-sonnet-4.6、gemini-3.1-pro-preview、qwen3.6-plus、glm-5.1、kimi-k2.5、deepseek-v4-flash），总共5194条execution trajectories。 几个关键结论 同模型换框架，综合分最大差距23.8分（nanobot 76.2 vs OpenClaw 52.4）。说明agent benchmark只报模型得分而不报框架配置是不够的。 Failure mode分析（Table 3）比较有参考价值：36.4%的失败是contract/format类，即agent产出了内容但格式不满足验证条件；24.6%是tool/recovery类，即工具调用出错后没能恢复。真正的推理错误只占一小部分。对框架设计的启示：容错和输出校验比堆模型能力更影响实际成功率。 强模型（gpt-5.4、claude-opus-4.6）跨harness的方差更小，中等模型对harness质量更敏感。好的harness能显著拉高中等模型的上限。 Token效率方面差异显著，同样任务不同harness消耗的token能差3-4倍，主要取决于上下文构建策略。 局限 全部是离线沙箱任务，没有在线服务、用户交互、长期记忆场景。LLM judge score 依赖LLM judge，引入了评估方的主观性。只测了配置级差异，没有因果分解。 Section 5提出的execution-alignment概念值得注意：框架的核心价值在于维持agent推理、workspace实际状态、工具返回结果、最终验证条件之间的对应关系，大多数失败的根本原因不是模型推理出错，而是agent的内部判断和外部实际状态脱节了，比如以为文件改对了其实没改，以为命令成功了其实报错了。 1 个帖子 - 1 位参与者 阅读完整话题