朝着一个无所不能的 harness 迈进
开发者们正在讨论如何最好地“harness”大型语言模型：是通过像提议中的 Ambiance 系统那样通用、Unix 风格、以文件为中心的框架，还是通过作用范围更窄、领域更专用的编排器，在 LLM 外围包裹工具和测试。一个反复出现的主题是尽可能把工作交给确定性的代码和脚本——只在需要判断和处理边缘情况时使用 LLM——同时还要应对 token 成本、可靠性、可审计性和平台限制等现实问题。许多人设想未来的 AI 工作流会更像可组合的 Unix 工具或操作系统级服务，LLM 只是轻量嵌入其中，而不是作为自主、四处游荡的 agent。
什么是“harness”，以及人们为何关心它
- harness 被描述为 LLM 和工具之间的胶水：它解析工具调用，运行命令（文件系统、网络等），并把结果反馈回去。
- 有些人把它看作一种“agentic 外骨骼”，或围绕一个本来模糊的模型搭建的确定性脚手架。
- 也有人嘲讽这个术语充满行话，但认可其背后的需求：约束并结构化 LLM 的行为。
确定性工作流 vs “纯” agent
- 一个强烈的趋势是偏向确定性：用真实代码和脚本来完成可重复的工作流；只在需要判断/边缘情况时调用 LLM。
- 提到的模式包括：决策树里大多数叶子都是“运行脚本”，少数是“询问 LLM”；用代码+测试作为骨架，把 LLM 当作偶尔的辅助。
- 人们描述把 Claude Code/Codex 之类工具包裹在外层确定性循环中（测试、git、安全检查、pre-commit hooks）。
- 一些框架（langgraph、ACP 等）被认为适合编排这些循环，不过也有人不喜欢那种让“构建 agent”显得像某种仪式化操作的系统。
Unix 哲学、“一切皆文件”，以及替代方案
- 许多人喜欢把 agent 概念映射到 Unix 原语：事件驱动工作流、作为共享状态的文件系统、FUSE、把“agent 当作 Linux 用户”来处理权限和邮件。
- 也有人反对把 “everything is a file” 套到 LLM 上，认为对模型来说“everything is tokens/embeddings”，向量数据库或类型化 JSON 更自然。
- 文件在一些人看来是务实的最低公分母：对人和模型都好用；另一些人则认为 FHS 已经过时，并建议采用类似 Nix/Plan 9 的思路。
通用 harness 与领域专用 harness
- 几个人认为领域专用的 harness（例如用于软件工程的）已经胜过通用方案：内置 ADR、规划、行为测试、严格门控。
- 把 LLM “裸奔”运行被比作没有刹车地开车；也有人表示自己已经放弃复杂的 harness，回到更简单的 CLI，因为额外复杂度并没有带来帮助。
成本、tokens 与实用性
- 有人担心针对文件系统监控或频繁轮询的 token 成本；建议改为在有意义的文件阈值触发时再执行。
- 有些人强调测试、日志以及最小化、不过度设计的脚本；过度泛化被视为维护陷阱。
对 Ambiance 以及“无所不能”说法的反应
- 正面评价：Unix 原生的心智模型、轻量且可审计的方法、一个可以在其上构建变体的好内核。
- 批评点：这些想法偏“软”，对比现有沙箱时具体收益不够明确；只支持 macOS 让一些人不满；“can do anything”的品牌宣传被认为有夸大之嫌。