不想围绕GC模型玩了，我想体验一下高智商模型+harness能达到什么效果 2 个帖子 - 2 位参与者 阅读完整话题
有没有佬友交流下，如何才能更好的运用Ai，有没有什么方法论，比如运用skill，mcp，Harness Engineering 可以交流下，怎么才能在工作中运用起来让脑子可以不那么累 2 个帖子 - 2 位参与者 阅读完整话题
怎么做 Harness Engineering.pdf (1.8 MB) 前两篇 【万字长文】什么是 Harness Engineering 文档共建 什么是 Harness Engineering.pdf (1.6 MB) 写了有四五天，用了AI帮助创作，收集了很多佬友的观点 聊聊为什么要 Harness Engineering，分享下我的观点 文档共建 继上一篇 【万字长文】什么是 Harness Engineering 为什么要 Harness Engineering.pdf (1.3 MB) 欢迎佬友们讨论 1 个帖子 - 1 位参与者 阅读完整话题
佬们 问一个cc编码先关的问题 就是cc里面怎么快速形成 Harness Engineering 开发 快速生成 rules spec AGENT_SYSTEM.md 这些文件或者文件夹里面对应的文件呀 4 个帖子 - 3 位参与者 阅读完整话题
看了很多harness的文章和实现 我大致总结了一下， hook就是将agent的生命周期拆分成几个钩子（简单示例） before agent before model input before tool exec after tool exec after model output after agent 在不同的时期程序介入处理 然后将hook实现+工具+skill+agent上下文打包成插件 就能实现一个基本的harness系统的架子 包括记忆、状态、鲁棒性、观测性、权限约束、上下文压缩 都能以hook+工具+skill+agent上下文打包一个插件来实现 并且很容易通过移除、添加不同的类似插件来实现扩展性 6 个帖子 - 4 位参与者 阅读完整话题
由于我已经一个web应用的harness的成功案例了，我想着可以基于该案例进行再往上抽象一层，构建一个harness的harness，目前我暂时命名 HarnessPipeline 。 本来是想命名为OpenHarness的，但是这个名字在github上已经有了，而且该作用与我想做的并不一样，为了避免理解冲突，就不重复了。 HarnessPipeline，我的初步想法是这样的： harness是基于领域区分的，比如web应用、三维空间、游戏等，这些harness肯定是截然不同的，所以这是第一区分维度 harness的验证应该具有各自领域的验证器的，比如web应用领域的是playwright主流点，其它领域我还不了解，所以想着这一步，由智能体解决，或者将来添加skill来解决 目前我的想法就这么多，还在做self-play，邀请佬们与我共建，有想法一起讨论。 1 个帖子 - 1 位参与者 阅读完整话题
The system prompts that coding agent harnesses pass to language models are massive. They describe every available tool in detail — even the ones you never use. So I wondered, what if I built something more minimal? I tend to work on small projects where all the code fits in the context window. So I built a harness with a single tool: the ability for an LLM to edit my files. The core algorithm: 1. Read every file in the project directory 2. Concatenate them with the user's prompt into a single message 3. Send it to any language model, instructed to respond with a message and a list of edits — each edit being a search and replace on a specific file 4. Apply the edits I tried getting the LLM to generate unified diffs, but it kept producing malformed ones. Search and replace turned out to be far more reliable — the model copies text verbatim from the files already in its context. This can be extended with a few more features: 1. A CLI that lets you continue the conversation or reset it. Dumber LLMs need this so it can see the mistake they made. 2. Automatic retries — if an edit fails, re-send the current files and have the LLM fix its own search blocks. 3. File deletion. I made it so that an empty search-and-replace on an empty file deletes it. The LLMs I tested were local ones running through the LM Studio API. Gemma 4 was pretty bad. Qwen 3.5 was significantly better. Where is the source code? You should be able to get any coding agent to generate you one using this post. Comments URL: https://news.ycombinator.com/item?id=47787383 Points: 3 # Comments: 0
For how lofty Anthropic’s Mythos claims are, the harness is confusingly stupid. From the report, it ranks every file by “how sus it sounds,” loops over each with curt instructions to “find a bug,” hands candidates to a judge + ASan checker— and zero-days simply pop out. That should not work. But it does. On miniupnp with a $20 plan, Opus 4.6 reliably rediscovers known CVEs in older versions and even surfaced a new remote global buffer overflow (non-default config). So what happens if the harness is actually good—i.e. equipped with proper security tooling? I’m a student, not a security engineer, so I'd would love ideas or critiques on my planned tool roadmap. (If you have a $200 plan with extra usage lying around, try it out to see if it churns a zero-day in your own C) Comments URL: https://news.ycombinator.com/item?id=47786408 Points: 3 # Comments: 0
今天去公司汇报，我写出来的harness 可以弥补glm-5和sonnet 4.6的差距，然后所有人都说我吹牛，我也真的是没事给自己找事做，我只好两段一样的提示词，同样往sonnet 4.6和glm-5+harness里面丢。 结果就是harness + glm-5的产出已经开始第二轮增强迭代了，sonnect 4.6的产出物，我这会还要用claude code给他修复bug。 顺便一提，我现在用上harness之后好焦虑啊，harness没有跑代码我就焦虑怎么能不跑代码呢，先跑上我好去干别的，软件人的职业病，并行。跑起来了我又在焦虑，这怎么要跑这么长时间啊，这harness的性能怎么能优化下呢。跑完了，我又开始焦虑了，唉，又要开始验证了。这一来二去，恍惚间都这个点了。 在这边给大家看下sonnet 4.6的劣质品，harness的成品在harness那边帖子上 6 个帖子 - 3 位参与者 阅读完整话题
Article URL: https://github.com/heliohq/ship Comments URL: https://news.ycombinator.com/item?id=47780120 Points: 2 # Comments: 1
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 我是完全不会开发游戏的，但是我现在突然就可以开发各种各样游戏了，因为我搞到一个绝世好SKILL， 分享给佬友： liang’s Godogen: 使用 Claude Code 构建完整 Godot 4 项目的技能 github地址： GitHub - liangdabiao/Godogen: liang's Godogen: 使用 Claude Code 构建完整 Godot 4 项目的技能集,你描述你想要的内容。AI pipeline 会设计架构、生成美术资源、编写每一行代码、从运行的游戏引擎中截取截图，并修复看起来不对的地方。输出是一个真正的 Godot 4 项目，包含组织良好的场景、可读的脚本和正确的游戏架构。 · GitHub 核心3点： 1， vibe coding 与AI助手协同创作 2, 可视化逻辑编辑, 直接在godot可以编辑 3， AI美术资源生成 一句话，开发游戏： ❯ 开发新游戏： 真人快打模式，以林冲为主角，背景为风雪山林 然后，AI连续工作半小时，生成如下游戏（简单游戏情况）： 所有设计架构-生成美术资源-编码-测试-运行-交付 ，全部都是AI. 复杂游戏也可以： 为什么AI可以运用 godot 4 主流游戏引擎创建游戏，核心就是： “驾驭工程”（harness engineering）：工程团队的首要工作不再是编写代码，而是让智能体能够有效工作。当出现问题时，解决方案从不是"再努力一把"，而是：缺少什么能力？如何让智能体能够理解并执行。 制作plan， 记录在文档，一步一步完成，测试，检查，修复，下一步： AI自动验证： 我们人类要给AI一个可以harness的环境和工具资源： 302.ai api 各种能力给ai, 自动检查，自动运行游戏截图检查， 自动玩游戏， 积累经验反馈。 要告诉 godot在哪里： “D:/Godot_v4.6.2-stable_win64.exe” 对话式 开发和修改游戏： AI给方案，然后工作： Ai自己按 人物状态利用nano banana 生成对应 美术资源动画： 总结 本项目是继承自一个开源项目：htdt/godogen 我大量修改和优化，更适合国内使用，更方便： GitHub - liangdabiao/Godogen: liang's Godogen: 使用 Claude Code 构建完整 Godot 4 项目的技能集,你描述你想要的内容。AI pipeline 会设计架构、生成美术资源、编写每一行代码、从运行的游戏引擎中截取截图，并修复看起来不对的地方。输出是一个真正的 Godot 4 项目，包含组织良好的场景、可读的脚本和正确的游戏架构。 · GitHub 总体测试开发了多个各种各样游戏，我觉得基本上用它开发游戏是可行的，目前第一版发布，有佬喜欢，我会继续开发吧，感谢佬友支持。 1 个帖子 - 1 位参与者 阅读完整话题
前两天刚学习了harness，今天有刷到个agent 自进化的 hermes，每天都在惊叹于大佬的惊才绝艳和自己的平平无奇，btw 智能体真是神仙打架，一堆几十k star的项目，想起了几个月前xhs还有一堆发帖找烧了上亿token的人当合伙人，只能说现实还是太魔幻了 Hermes 仓库地址： Hermes Harness 太多了，简单挑了一个 仓库地址： Oh My OpenCode 一句话总结核心区别 oh-my-openagent 是一个通过并行调度多模型（Claude/GPT等）来为现有编程助手提供极致效率增强的“外挂”工具（主打极速编程自动化）； hermes-agent 是一个主打长期记忆、能从经验中自我学习进化，并支持在多平台（如终端、微信、Telegram）独立运行的全能型智能体框架（主打自我成长与全场景陪伴）。 4 个帖子 - 4 位参与者 阅读完整话题
langchain4j spring-ai spring-ai-alibaba agentscope-java 不使用agent框架，使用原生openai、anthropic官方最小SDK自己搭建 点击以查看投票。 公司最近想开发一个harness类项目，我感觉harness工程定制化程度还挺高的，并没有一个很通用的标准，不知道这些agent框架能否满足，后面扩展会不会成为包袱，还是仅使用官方最小sdk来搭建，后续方便扩展？ 1 个帖子 - 1 位参与者 阅读完整话题
主题是从我最近有感而发而来的，纯头脑风暴内容，逻辑不准甚至名词错用都很正常。 Texiwustion: 04-15 07:11:55 技术防线非常脆弱，你很难说你垄断某项技术，或者乐观地说，一旦你暴露了技术，你就能被无限token“攻击”和蒸馏 Texiwustion: 04-15 07:51:44 但你的技术，（编辑时ps：如果要表达，）现在的一个不错的表达方式也是经由agent创造与计划落地 Texiwustion: 04-15 07:52:27 弄一个human note在harness流程中，人不会完全没有表达，human note又要（自动 or 手动？）集合到卡片盒（帖子编辑时ps：这是我目前主用的笔记法）中 Texiwustion: 04-15 07:53:19 卡片盒不是非用不可，但技术被落地使用了，也没有被证伪，没理由落地而不用 Texiwustion: 04-15 08:41:12 有没有可能有这样一个社群，人可以随意往群里丢自己的想法，别人可以看自己兴趣把某些idea蹬出来（也在群里分享蹬的过程？） 1 个帖子 - 1 位参与者 阅读完整话题
I've been running Claude Code and Codex together every day. At some point I figured out you can use tmux to let them talk to each other, so I started doing that. Once they could coordinate, I kept adding more agents. Before long I had a whole team working together. But any time I rebooted my machine, the whole thing was gone. Not just the tabs. The way they were wired up, what each one was doing, all of it. Nothing I'd found treats your agent setup as a topology, as something with a shape you can save and bring back. So I built OpenRig, a multi-agent harness. A harness wraps a model. A "rig" wraps your harnesses. You describe your team in a YAML file, boot it with one command, and get a live topology you can see, click into, save, and bring back by name. Claude Code and Codex run together in the same rig. tmux is still doing the talking underneath. I didn't try to add a fancier messaging layer on top. The project is still early. My own setup uses the config layer extensively (YAML, Markdown, JSON) for prototyping functionality that outpace what's shipped in the repo and npm package. But the core primitives are there and the happy path in readme works. It's built to be driven by your agent, not by you typing commands by hand. README: https://github.com/mvschwarz/openrig Demo: https://youtu.be/vndsXRBPGio Comments URL: https://news.ycombinator.com/item?id=47772935 Points: 4 # Comments: 1
Article URL: https://api.melonpost.com/SKILL.md Comments URL: https://news.ycombinator.com/item?id=47770547 Points: 2 # Comments: 1
之前做过一些AI应用的项目。踩过一些坑。最近整理了一些想法。贴出来跟大家交流一下。 过去几年，AI 应用工程的关注重点发生了一次非常清晰的迁移。早期开发者最关心的是，怎样写 prompt，才能让模型更稳定地理解指令、输出正确格式、减少跑题和幻觉。随后，随着长上下文、检索增强、工具调用和多轮状态管理逐渐成熟，问题转向了另一个方向：怎样为模型提供它在当前任务中真正需要的信息。再往前一步，当模型开始具备跨步骤执行复杂任务的能力，一个更深层的挑战浮现出来：即使模型已经理解任务，也拿到了足够的信息，怎样才能让它持续、可靠、可验证地把工作做完。 如果把这三个阶段放在一起看，就会发现它们并不是零散技巧的更替，而是 AI 应用工程的三层递进问题。第一层是 Prompt Engineering，解决的是如何表达意图；第二层是 Context Engineering，解决的是如何供给信息；第三层是 Harness Engineering，解决的是如何约束行为、验证结果并维持系统可靠性。它们共同构成了 AI Agent 从“能回答”走向“能工作”的一条演化路径。 Prompt关心的是接口，Context关心的是认知环境，Harness关心的是系统约束。理解这三层之间的关系，不仅能帮助我们解释行业讨论为何会从“提示词”转向“上下文”，再进一步转向“agent harness”，也能帮助团队在实践中更准确地判断：一个问题究竟应该在 prompt 层解决，在 context 层解决，还是必须上升到 harness 层解决。 Prompt Engineering 是最早出现、也最容易被大家感知的一层。原因很简单：在大模型开放 API 的早期，开发者最直接、往往也是唯一能控制的变量，就是输入给模型的那段文本。无论是最初的文本补全接口，还是后来的对话式界面，开发者首先面对的问题都是“怎么说，模型才更容易照着做”。因此，Prompt Engineering 的兴起并不神秘，它几乎是由交互形态本身决定的。模型能力尚不稳定时，表达方式自然成为第一控制杠杆。 Prompt 的作用，就是在人类意图与模型生成行为之间建立一个尽可能清晰、低歧义、可重复的接口。角色设定、示例提供、格式约束、分步指令，这些常见技术本质上都在做同一件事：让模型更准确地映射人的意图。但 Prompt Engineering 的边界也始终存在。它擅长解决的是“怎么表达”带来的偏差，却无法凭空补齐模型没有看到的信息，更无法独立解决跨轮次记忆、多工具协作、长任务验证和系统级恢复这些问题。当任务复杂度提升到一定程度，仅靠 prompt 写得更好，往往已经不够。 这正是 Context Engineering 兴起的背景。随着模型的上下文窗口扩大、工具调用能力增强、RAG 和各类记忆机制逐渐成熟，开发者开始越来越明显地感受到：很多失败并不是因为 prompt 写得不够好，而是因为模型没有在当下看到正确的信息。它可能不知道最新政策，不了解企业内部知识，不记得前几轮对话已经确认的决定，也可能虽然拿到了信息，却因为注入方式混乱而无法有效使用。到了这个阶段，问题的重心就从“如何提问”转向了“模型该看到什么”。 Context Engineering 的核心，不是简单地往上下文里塞更多内容，而是系统性地设计模型的认知环境。检索哪些材料、保留哪些历史、怎样压缩长文档、如何组织工具描述、哪些状态需要长期持久化、哪些信息应该在当前轮动态注入，这些都属于 Context Engineering 的范畴。它解决的是信息供给问题：在上下文窗口有限的前提下，如何在正确的时刻把正确的信息放进模型可见范围内。 这一层之所以重要，是因为大模型的很多“不会”，本质上不是能力缺失，而是信息缺席。模型在很多任务中并非不具备推理能力，而是推理所依赖的事实、状态和材料没有被正确供给。随着 AI 应用从聊天问答走向文档助手、代码代理、企业知识系统和工具增强型 agent，Context Engineering 逐渐从辅助环节变成主导环节，也就不难理解了。 但即便如此，一个拿到了正确信息的agent，仍可能在长任务中偏离目标，可能在没有验证结果的情况下过早宣布完成，可能持续复制代码库中的坏模式，可能在多次操作中悄悄积累错误，最终把本来局部可控的问题放大成系统性风险。到了这里，问题已经不再是信息供给，而是行为约束和系统可靠性。 Harness Engineering 之所以成为新的焦点，正是因为 agent 的失败模式已经超出了 prompt 和 context 两层能够单独解决的范围。Harness 所指向的，不是更多提示词，也不是更大的上下文，而是一整套包裹模型工作的外部系统：项目规则、状态文件、架构约束、自动化测试、静态检查、任务分解、反馈回路、回滚机制、子智能体编排，以及让错误能被发现、被反馈、被修正的全部工程设施。 如果说 Prompt 是告诉模型你要什么，Context 是让模型看到完成任务所需的信息，那么 Harness 做的就是让模型在真实系统里以可接受的方式把事情做成。它不是替代前两者，而是在前两者之上增加了一层对行为的调控。这个变化之所以关键，是因为一旦模型开始长时间自主工作，“回答对一个问题”就不再是核心标准，“能否持续在边界内完成一项任务”才是。 这也是为什么越来越多关于 agent 的高价值讨论，不再把注意力集中在单次输出质量，而是开始关注智能体的工作环境。没有测试的 agent 会自信地交付未验证结果，没有状态管理的 agent 会在跨会话中失忆，没有结构约束的 agent 会在代码库里不断扩散局部最优，没有反馈回路的 agent 即使犯了同一种错也会反复重演。换句话说，agent 的问题越来越像软件工程问题，而不再只是模型调用问题。 1 个帖子 - 1 位参与者 阅读完整话题
Harness Engineering 的执行核心是一种叫做 Ralph Loop 的编排模式 AI—>概率模型 AI agent处理复杂任务—>没有一个足够好的环境、约束以及反馈机制 Ralph Loop—>让AI持续工作直到真正完成—>解决AI编程助手"半途而废"问题的创新方法—》通过Stop Hook 拦截机制，让AI在未完成任务时无法退出， 通过文件系统、测试结果和Git历史形成自我参照的迭代循环—>专注于可验证任务的持续迭代修正，不依赖LLM主观判断 痛点：AI编程助手为何总是"半途而废 在使用AI编程工具时，开发者经常遭遇以下困境： 过早退出：AI在它认为"足够好"时就停止工作，而非真正完成任务 单次提示脆弱：复杂任务无法通过一次提示完成，需要反复人工干预 重新提示成本高：每次手动重新引导都在浪费开发者时间 上下文断裂：绘画重启后，之前的所有进展和上下文全部丢失 问题本质：LLM的自我评估机制不靠谱—>它会在主观认为"完成"时退出，而非达到客观可验证的标准 解决思路：让 AI 持续工作直到真正完成 Claude Code 社区诞生了一种极简但有效的范式——Ralph Loop（也称 Ralph Wiggum Loop）： bash命令 while :; do cat PROMPT.md | claude-code --continue done 核心思想：同一个提示反复输入，让 AI 在文件系统和 Git 历史中看到自己之前的工作成果 Ralph Loop 让大语言模型持续迭代、自动运行直到任务完成，而不在典型“一次性提示 → 结束”循环中退出。这种范式已经被集成到主流 AI 编程工具和框架中， 被一些技术博主和开发者称作"AI 持续工作模式" Ralph Loop 让 AI 代理持续迭代直到任务完成 核心三要素： 明确任务+完成条件：定义可验证的成功标准 Stop Hook阻止提前退出：未达标时强制继续 max-iterations安全阀：防止无限循环 — 安装插件 /plugin install ralph-wiggum@claude-plugins-official — 运行循环任务 /ralph-loop “任务描述” --completion-promise “COMPLETE” --max-iterations 50 任务描述例子：“为当前项目添加单元测试 Completion criteria: - Tests passing (coverage > 80%) - Output COMPLETE” Ralph Loop 概述 不是简单的一次性运行，而是持续迭代直到完成任务 循环使用同一个prompt，但外部状态（代码、测试输出、文件等）在每次迭代后发生改变 需要明确的完成条件（如输出特定关键字、测试通过等）和合理的最大迭代次数作为安全控制 常规智能体的一个核心痛点是"上下文腐烂（Context Rot）"—>随着对话轮次的增加，LLM 对早期指令的注意力和精确度会线性下降 Ralph 循环通过“刷新上下文”解决了这一问题： 每一轮循环都可视作一个全新对话，智能体不再从臃肿的历史记录中读取状态 智能体直接通过文件读取工具扫描当前的项目结构和日志文件 这种模式将"状态管理"从 LLM 的内存（Token 序列）转移到了硬盘（文件系统） 确保Agent执行任务是否正确—>观测性 一个完整的可观测性站包含三层数据： LOGS—>日志 发生了什么事？记录每一步的行为与结果，用于事后溯源 OTLP METRICS—>指标 系统健康状况如何？延迟、错误率、吞吐量等数字化度量 OTLP TRACE—>链路追踪 一次请求从头到尾经过了哪些环节？完整的执行路径还原 这三层数据汇入向量存储库，供 Agent 自主查询。整个推理链路如下： Query 查询→Correlate 关联分析→Reason 推理原因→Implement Change→Re-run 验证 目标是自主定位问题、自主修复、自主验证—>这个闭环就是 Feedback Loop，是 Harness Engineering 的重点。 这套可观测性架构直接驱动 Agent 的代码修改行为：Agent 读到指标异常，分析 trace 找到根因，生成 PR，重启应用，重跑 workload，直到验证通过 约束先于能力—>好的架构不依赖人的自觉，而是用工具强制执行 渐进式披露的思想参考模板 project/ ├── AGENTS.md ← 地图，约 50-100 行，只做导航 ├── ARCHITECTURE.md ← 系统全貌，组件间的依赖关系 ├── docs/ │ ├── design-docs/ ← 为什么这样设计 │ └── core-beliefs.md ← 团队工程价值观 ├── exec-plans/ │ ├── active/ ← 正在做什么 │ └── completed/ ├── tech-debt-tracker.md ├── references/ ← 工具文档（为 LLM 裁剪的版本） └── FRONTEND.md ← 端层实践切分文档 三个维度，一个闭环 编码—>执行环境—>Ralph Loop保证Agent在受控的单步循环中执行，每步可验证，可回滚 研究—>观测系统—>可观测性栈让Agent的行为透明化，支持自主定位和修复问题 设计—>规范框架—>文档结构和工程原则把约束写入系统，而非依赖认为记忆自觉 找出 Agent 缺哪方面的知识或工具，然后给他补上—>这是 Harness Engineering 的日常工作。不是调模型，而是完善 harness（挽具）本身. 3 个帖子 - 2 位参与者 阅读完整话题
前面把 memory 这条线拆了一遍，这两天我又把仓库里的 harness 专题做完了。 上一篇相关帖子在这里，也顺手关联一下： https://linux.do/t/topic/1867372/34 这次我最大的感受是： 很多人讨论 Agent 稳定性时，默认还停留在两个层面： Prompt 有没有写清楚 Context 有没有喂够 但只要系统真的开始做事，比如进浏览器、调工具、跑多步骤链路，问题就已经不是“模型答得对不对”了，而是： 系统还能不能持续做对。 这也是为什么我越来越觉得，很多 Agent 失稳问题，本质上不是模型问题，而是 Harness 问题。 以下为AI生成内容 6 个帖子 - 4 位参与者 阅读完整话题
今天用了一下豆包的对话模式，真的被蠢到厌蠢症发作了，思考默认very low，各种幻觉，上下文巨小，上来就是我给你几个最XX，最XX，最XX的版本。 不带harness的大模型实在太蠢啦！ btw，又是蹬不到公益站的一天。 1 个帖子 - 1 位参与者 阅读完整话题