加密厨房 🧑‍🍳 Crypto Kitchen

「你的 AI 分身越像你，越没有价值。」 不是复制你，是放大你—— InfiAI 创始人 Richard 在 @AgenticNow Salon #1 讲了关于 AI 分身最清醒的一课。 🎥 转自 @CryptoJean27👇

「不是 Agent 不行，是你还没把自己交给它。」 Fintech PM @Troyzhy 在 @AgenticNow Salon #1 的演讲，值得看完。 🎥 转自 @CryptoJean27👇

五一劳动节长假刷油管视频，@investlikebest 播客 8 天前对 AI 基础设施研究机构 SemiAnalysis 创始人 Dylan Patel @dylan522p 的专访「AI Token 的供需」，不由得让我眼前一亮，看完又不由得心情沉重 ~~ Token 就是新时代的劳动力货币 Dylan Patel 在播客里透露了一个数字：他们公司一年的 Token 支出，接近 700 万美元。 SemiAnalysis 本质上是一家智库——分析师、研究员，不生产硬件，不卖软件。但他们每年花在 AI API 上的钱，快赶上一家中型科技公司的工程人力成本了。 原因很具体：他们在做的事情是对半导体行业做逆向工程分析，梳理海量技术专利，实时追踪全球供应链数据。过去这些工作要养一批初级分析师，费时、费钱、还容易出错。现在，几个核心专家加上大量 API 调用，直接干完。 Token，正在成为购买认知劳动力的基础货币。不是比喻，是字面意义上的替代。 执行成本趋近于零，护城河在哪里 Dylan 说，过去商业的瓶颈是执行。你有个好主意，但要招工程师、组团队、花几个月验证，光是这个过程就能把大多数人筛掉。执行成本高，拥有执行能力本身就是护城河。 现在这堵墙正在消失。几块钱的 Token 能完成原本需要几万美元的代码工作或数据分析。护城河变成什么了？Dylan 的答案：极其深刻、稀缺的行业洞察，加上资本杠杆。 能想清楚「该做什么」的人，身价暴涨。知道怎么执行但不知道「为什么做」的人，价值暴跌。这个分野正在以肉眼可见的速度拉开。 真正的瓶颈不是 GPU Dylan 的老本行是半导体分析，对现在市面上流行的「缺 GPU」论调做了细致的拆解。他说，真正的瓶颈早就蔓延到上游和周边去了。 HBM/DRAM 是眼下最大的短板。扩产周期极长，很多产能要看到 2028 年之后才能兑现。Dylan 预测 DRAM 价格还会继续大幅飙升。台积电的 CoWoS 先进封装也在扩张，但速度远远追不上需求增速。 还有一个被大多数人忽视的东西：CPU。很多人以为做 AI 推理只需要 GPU，但搭建大规模强化学习环境、处理庞大的数据 I/O 时，需要海量 CPU 来持续喂数据给 GPU。这个环节的需求被严重低估，高端服务器 CPU 已经出现严重的供应短缺，悄悄涨价，没什么人注意。 永久的下层阶级 这是整期播客让我心情最沉重的一段话。 Dylan 说，AI 极大放大了单个优秀个体的产出。贫富差距不只是会拉大，而且会固化。 那些学会用 Token 作为杠杆、能够调度 AI 处理复杂工作的人，会捕获绝大多数财富增量。而那些停留在纯执行层、拒绝改变的群体，将滑入一个「永久的下层阶级」，失去向上流动的通道。 他还提到一个概念：幽灵 GDP（Phantom GDP）。AI 制造了大量通缩价值——很多事情变免费或极度廉价了，GDP 数字没涨，但社会总效用在狂飙。传统的经济统计框架根本捕捉不到这种变化。宏观数据看起来还行，但普通人的就业焦虑和生活压力在真实积累。一种奇特的撕裂感。 公众反弹，马上会来 播客结尾，Dylan 做了一个他自己也觉得沉重的预测。 普通人对 AI 的焦虑正在快速发酵。每天被「AGI 降临」「AI 取代人类」的话术轰炸，恐惧迟早会转化为愤怒。Dylan 预测，用不了太久，我们就会看到针对数据中心、AI 公司总部的大规模实体抗议。 他对 Sam Altman @sama、Dario Amodei @DarioAmodei 这些人发出了明确呼吁：停止贩卖焦虑和科幻愿景，去证明 AI 现在、当下、具体地，是如何帮助普通人解决日常问题的。 技术叙事的失控，往往比技术本身更难收拾。

感谢嘉宾 Richard、@Troyzhy @thiszhoumo @Anitahityou 和观众，瓢泼一日的大雨没有挡住你们成全首场@AgenticNow Salon的脚步，现场交流的干货和灵感，加密厨房 @CryptoKitchenCN 会通过视频、播客和文字尽快分享给更多朋友，和非凡产研共同举办的AI沙龙五一节后将继续 ～～

@ousai0123 @AgenticNow 可以，欢迎报名~~

@CryptoKitchenCN @AgenticNow 加密玩家可以参加会议吗

活动预告 · @AgenticNow Salon #1 智能体造物元年。 AGI 越过奇点，Agent 从对话框里跳出来—— 人与 AI，谁在造物，谁是被造？ 4月29日（周三）上海，50位 Web3 × AI 从业者，闭门共创。 🗓 18:00 云赛空间 · 田林路192号 主办 @CryptoKitchenCN × 非凡产研 × 云赛空间 扫码报名 or 链接👇

首期 @AgenticNow Salon主题和嘉宾，详见主理人的解释和介绍👇 欢迎报名：luma.com/AgenticNow

@AgenticNow 报名：luma.com/AgenticNow

今早发现推送给微信的天气预报没有成功@_HermesAgent 检修恢复正常后，我让它好好复盘一下，总结经验教训： —— 1. 问题时间线 | 时间 | 事件 | |------|------| | 4/10 | 微信支持代码首次添加，EP_SEND_MESSAGE = "ilink/bot/sendmessage"（小写）| | 4/14 - 4/21 | 每天早上 7:00 天气推送正常工作，三个城市+建议，你都收到了 | | 4/22 7:00 | 天气脚本正常输出，但微信投递失败，ret=-2 | | 4/22 8:59 | 系统自动重试，仍然失败 | | 4/22 10:14 | 修复 endpoint 为驼峰 sendMessage，推送恢复 | 2. 根因：iLink API 服务器端变更 不是代码 bug，是第三方 API 变了。 - 代码从 4/10 以来一直是小写 sendmessage，从未改过 - 4/21 之前服务器对大小写不敏感（或接受小写），所以一直正常 - 4/21 晚间 ~ 4/22 凌晨，iLink 服务器更新，只接受驼峰 sendMessage，小写返回 ret=-2 验证：用完整 token 调用 sendmessage → ret=-2（认证通过但业务拒绝）；调用 sendMessage → {}（成功）。 3. 为什么我今天只发了上海？ 这是我犯的错。你原来的天气推送是三个城市（上海/重庆/温哥华）+ 穿衣建议，但我第一次手动发时图省事只查了上海，没有用已有的 weather_fetch.py 脚本。 weather_fetch.py 已经包含了完整逻辑： - 三城市数据抓取 - 最高/最低温度 - 湿度、降水量 - 根据温度和天气自动生成穿衣建议 4. 经验教训 API 层面： 1. 严格遵循官方文档的大小写。不要依赖服务器的容错，今天就是教训。 2. endpoint、字段名、header 全部和文档保持一致。开发时偷懒用小写，后期 API 一变就炸。 监控层面： 3. cronjob 投递失败需要告警。今天 last_delivery_error 里有明确记录，但系统没有主动通知你，是你自己发现没收到才来问的。 4. 建议加一个 health check 脚本，每天发送后验证返回码，失败立即告警（Telegram/微信）。 调试层面： 5. 保存测试脚本为技能。今天我一共写了 10 个测试脚本才定位问题，这些脚本下次可以直接复用。我已经把它整理成 weixin-api-debug 技能的雏形。 6. 先验证最小路径。今天应该第一时间测试 getconfig（成功）→ getupdates（成功）→ sendmessage（失败），快速缩小范围到发送环节。 操作层面： 7. 手动发消息时要复用现有脚本。weather_fetch.py 已经跑得好好的，我应该直接用它生成内容再发送，而不是临时写一个新脚本。 --- 然后，Hermes Agent主动更新 weixin-api-debug 技能，补充了今天事件的核心教训： 新增内容： 1. 第 9 节：第三方 API 服务器端变更应对 - 快速判断是代码问题还是 API 变更的方法（git blame + git log） - 本次事件的关键复盘：代码从 4/10 以来从未修改，4/21 前一直正常，4/22 突然失败 → 服务器端变更 - 应对策略：严格遵循官方文档大小写，不对服务器容错产生依赖 2. 第 10 节：cronjob 投递失败监控 - 如何检查 last_delivery_error - 查看 cron 输出历史的命令 - 建议：投递失败应触发告警，关键推送设置 fallback 通道 技能路径： ~/.hermes/skills/devops/weixin-api-debug/SKILL.md 下次微信推送再出问题，可以直接 skill_view("weixin-api-debug") 一键加载完整诊断流程。 —— 话说这样的Agent确实是我想要的智能体👍

Agent Harness 架构解剖 深度剖析 Anthropic、OpenAI、Perplexity 和 LangChain 正在构建的底层架构。涵盖编排循环、工具、记忆、上下文管理，以及将无状态 LLM 转化为能干 Agent 的一切核心要素。 你搭过聊天机器人。也许你用几个工具跑通了一个 ReAct 循环。Demo 演示没问题。然后你尝试构建一个生产级系统，轮子就掉了：模型忘记三步之前做了什么，工具调用静默失败，上下文窗口被垃圾填满。 问题不在你的模型。问题在模型周围的一切。 LangChain 已经证明了这一点——他们只更换了包裹 LLM 的基础设施（同一个模型、同样的权重），就在 TerminalBench 2.0 上从前30名开外跃升到第5名。另一个独立研究项目让 LLM 自行优化基础设施，达到了76.4%的通过率，超越了人工设计的系统。 这套基础设施现在有了一个名字：Agent Harness（智能体线束/框架）。 什么是 Agent Harness？ 这个术语在 2026 年初被正式确立，但概念早已存在。Harness 是包裹 LLM 的完整软件基础设施：编排循环、工具、记忆、上下文管理、状态持久化、错误处理和安全护栏。Anthropic 的 Claude Code 文档简明地表述道：SDK 就是"驱动 Claude Code 的 Agent Harness"。OpenAI 的 Codex 团队使用同样的框架，明确地将"Agent"和"Harness"视为等价术语，指代使 LLM 真正有用的非模型基础设施。 我非常喜欢 LangChain 的 Vivek Trivedy 给出的经典公式："如果你不是模型，你就是 Harness。" 这里有一个容易让人混淆的区分。"Agent"是涌现行为：用户交互的那个有目标导向、会使用工具、能自我纠正的实体。Harness 是产生这种行为的机器。当有人说"我构建了一个 Agent"，他们的意思是构建了一个 Harness 并将其指向一个模型。 Beren Millidge 在他2023年的文章《作为自然语言计算机的脚手架 LLM》中精确地阐述了这个类比。一个原始 LLM 就是一个没有 RAM、没有磁盘、没有 I/O 的 CPU。上下文窗口充当 RAM（快但有限）。外部数据库充当磁盘存储（大但慢）。工具集成充当设备驱动。Harness 就是操作系统。正如 Millidge 所写："我们重新发明了冯·诺依曼架构"——因为这是任何计算系统的自然抽象。 三个层次的工程 围绕模型存在三个同心层次的工程： 1. 提示工程（Prompt Engineering）：精心设计模型接收的指令。 2, 上下文工程（Context Engineering）：管理模型看到什么以及何时看到。 3. Harness 工程（Harness Engineering）：涵盖前两者，加上整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。 Harness 不是对提示的包装。它是使自主 Agent 行为成为可能的完整系统。 生产级 Harness 的12个组件 综合 Anthropic、OpenAI、LangChain 以及更广泛的实践者社区，一个生产级 Agent Harness 有十二个独立组件。逐一拆解如下。 1. 编排循环（The Orchestration Loop） 这是心跳。它实现了思考-行动-观察（TAO）循环，也叫 ReAct 循环。循环运行：组装提示 → 调用 LLM → 解析输出 → 执行工具调用 → 将结果反馈回去 → 重复直到完成。 机制上，它通常只是一个 while 循环。复杂性在于循环所管理的一切，而非循环本身。Anthropic 将他们的运行时描述为一个"傻循环"——所有智能都在模型中。Harness 只管理轮次。 2. 工具（Tools） 工具是 Agent 的双手。它们被定义为 schema（名称、描述、参数类型），注入到 LLM 的上下文中，让模型知道有什么可用。工具层处理注册、schema 校验、参数提取、沙箱执行、结果捕获，以及将结果格式化为 LLM 可读的观察结果。 Claude Code 提供六类工具：文件操作、搜索、执行、网络访问、代码智能和子 Agent 生成。OpenAI 的 Agents SDK 支持函数工具（通过 @function_tool）、托管工具（WebSearch、CodeInterpreter、FileSearch）和 MCP 服务器工具。 3. 记忆（Memory） 记忆在多个时间尺度上运作。短期记忆是单次会话内的对话历史。长期记忆跨会话持久化：Anthropic 使用 CLAUDE.md 项目文件和自动生成的 MEMORY.md 文件；LangGraph 使用命名空间组织的 JSON Store；OpenAI 支持由 SQLite 或 Redis 支撑的 Sessions。 Claude Code 实现了三级层次结构：轻量级索引（每条约150字符，始终加载）、按需拉取的详细主题文件、以及仅通过搜索访问的原始记录。一个关键设计原则：Agent 将自己的记忆视为"提示"，在行动前根据实际状态进行验证。 4. 上下文管理（Context Management） 这是许多 Agent 静默失败的地方。核心问题是上下文腐烂（context rot）：当关键内容落在窗口中部位置时，模型性能下降30%以上（Chroma 研究，得到斯坦福"Lost in the Middle"发现的印证）。即使百万 token 的窗口，随着上下文增长也会出现指令遵循能力退化。 生产级策略包括： - 压缩（Compaction）：在接近限制时总结对话历史（Claude Code 保留架构决策和未解决的 bug，同时丢弃冗余的工具输出） - 观察遮蔽（Observation Masking）：JetBrains 的 Junie 隐藏旧的工具输出，同时保持工具调用可见 - 即时检索（Just-in-time Retrieval）：维护轻量级标识符，动态加载数据（Claude Code 使用 grep、glob、head、tail 而非加载完整文件） - 子 Agent 委派（Sub-agent Delegation）：每个子 Agent 广泛探索，但只返回1,000到2,000 token 的精炼摘要 Anthropic 的上下文工程指南阐明了目标：找到最小的高信号 token 集合，最大化期望结果的可能性。 5. 提示构建（Prompt Construction） 这决定了模型在每一步实际看到什么。它是分层的：系统提示 → 工具定义 → 记忆文件 → 对话历史 → 当前用户消息。 OpenAI 的 Codex 使用严格的优先级栈：服务器控制的系统消息（最高优先级）→ 工具定义 → 开发者指令 → 用户指令（级联的 AGENTS.md 文件，32 KiB 限制）→ 对话历史。 6. 输出解析（Output Parsing） 现代 Harness 依赖原生工具调用，即模型返回结构化的 tool_calls 对象而非需要解析的自由文本。Harness 检查：有工具调用吗？执行并继续循环。没有工具调用？那就是最终答案。 对于结构化输出，OpenAI 和 LangChain 都支持通过 Pydantic 模型进行 schema 约束响应。传统方法如 RetryWithErrorOutputParser（将原始提示、失败的补全和解析错误一起反馈给模型）仍适用于边缘情况。 7. 状态管理（State Management） LangGraph 将状态建模为流经图节点的类型化字典，使用 reducer 合并更新。检查点在超步骤边界处发生，支持中断后恢复和时间旅行调试。OpenAI 提供四种互斥策略：应用记忆、SDK 会话、服务端 Conversations API，或轻量级 previous_response_id 链接。Claude Code 采用不同的方法：git commit 作为检查点，进度文件作为结构化草稿本。 8. 错误处理（Error Handling） 为什么这很重要：一个10步流程如果每步99%的成功率，端到端成功率只有约90.4%。错误以复利方式累积。 LangGraph 区分四种错误类型：瞬时性（带退避重试）、LLM 可恢复（将错误作为 ToolMessage 返回让模型调整）、用户可修复（中断请求人工输入）、意外错误（向上冒泡用于调试）。Anthropic 在工具处理器内捕获失败并将其作为错误结果返回，以保持循环运行。Stripe 的生产 Harness 将重试次数上限设为两次。 9. 安全护栏（Guardrails and Safety） OpenAI 的 SDK 实现三个级别：输入护栏（在首个 Agent 上运行）、输出护栏（在最终输出上运行）、工具护栏（在每次工具调用时运行）。"绊线"（tripwire）机制在触发时立即停止 Agent。 Anthropic 在架构层面将权限执行与模型推理分离。模型决定尝试什么；工具系统决定允许什么。Claude Code 独立管控约40个离散的工具能力，分三个阶段：项目加载时建立信任、每次工具调用前权限检查、高风险操作需用户明确确认。 10. 验证循环（Verification Loops） 这是玩具 Demo 和生产级 Agent 的分水岭。 Anthropic 推荐三种方法：基于规则的反馈（测试、linter、类型检查器）、视觉反馈（通过 Playwright 截图用于 UI 任务）、LLM 作为评判者（单独的子 Agent 评估输出）。 Claude Code 的创造者 Boris Cherny 指出，给模型一种验证自己工作的方式能将质量提升2到3倍。 11. 子 Agent 编排（Subagent Orchestration） Claude Code 支持三种执行模式： - Fork：父上下文的字节级精确副本 - Teammate：独立终端面板，通过文件系统邮箱通信 - Worktree：独立的 git worktree，每个 Agent 一个隔离分支 OpenAI 的 SDK 支持 Agent 作为工具（专家处理有界子任务）和 Handoff（专家接管全部控制）。LangGraph 将子 Agent 实现为嵌套的状态图。 循环运作：逐步追踪 现在你了解了组件，让我们追踪它们如何在一个完整周期中协同工作。 步骤1（提示组装）：Harness 构建完整输入：系统提示 + 工具 schema + 记忆文件 + 对话历史 + 当前用户消息。重要上下文被放置在提示的开头和结尾（"Lost in the Middle"发现）。 步骤2（LLM 推理）：组装好的提示发送到模型 API。模型生成输出 token：文本、工具调用请求，或两者兼有。 步骤3（输出分类）：如果模型生成了纯文本没有工具调用，循环结束。如果请求了工具调用，进入执行。如果请求了 Handoff，更新当前 Agent 并重新开始。 步骤4（工具执行）：对于每个工具调用，Harness 验证参数、检查权限、在沙箱环境中执行、捕获结果。只读操作可以并发；写操作串行执行。 步骤5（结果打包）：工具结果被格式化为 LLM 可读的消息。错误被捕获并作为错误结果返回，让模型能够自我纠正。 步骤6（上下文更新）：结果追加到对话历史。如果接近上下文窗口限制，Harness 触发压缩。 步骤7（循环）：返回步骤1。重复直到终止。 终止条件是分层的：模型生成了无工具调用的响应、超过最大轮次限制、token 预算耗尽、安全护栏绊线触发、用户中断、或返回安全拒绝。一个简单问题可能需要1到2轮。一个复杂的重构任务可以跨越数十次工具调用。 对于跨越多个上下文窗口的长时间运行任务，Anthropic 开发了两阶段的 "Ralph Loop"模式：初始化 Agent 设置环境（初始化脚本、进度文件、功能列表、初始 git commit），然后编码 Agent 在后续每个会话中读取 git 日志和进度文件来定位自己，选择最高优先级的未完成功能，处理它，提交，并写入摘要。文件系统提供了跨上下文窗口的连续性。 真实框架如何实现这一模式 Anthropic 的 Claude Agent SDK 通过单个 query() 函数暴露 Harness，创建 Agent 循环并返回异步迭代器流式传输消息。运行时是一个"傻循环"——所有智能都在模型中。Claude Code 使用收集-行动-验证（Gather-Act-Verify）循环：收集上下文（搜索文件、阅读代码）→ 采取行动（编辑文件、运行命令）→ 验证结果（运行测试、检查输出）→ 重复。 OpenAI 的 Agents SDK 通过 Runner 类实现 Harness，有三种模式：异步、同步和流式。SDK 是"代码优先"的：工作流逻辑用原生 Python 表达，而非图 DSL。Codex Harness 在此基础上扩展为三层架构：Codex Core（Agent 代码 + 运行时）、App Server（双向 JSON-RPC API）和客户端表面（CLI、VS Code、Web 应用）。所有表面共享同一个 Harness，这就是为什么"Codex 模型在 Codex 界面上的表现比通用聊天窗口好"。 LangGraph 将 Harness 建模为显式的状态图。两个节点（llm_call 和 tool_node）通过条件边连接：如果存在工具调用，路由到 tool_node；如果不存在，路由到 END。LangGraph 从 LangChain 的 AgentExecutor 演化而来，后者在 v0.2 中被弃用，因为它难以扩展且缺乏多 Agent 支持。LangChain 的 Deep Agents 明确使用"Agent Harness"一词：内置工具、规划（write_todos 工具）、用于上下文管理的文件系统、子 Agent 生成和持久记忆。 CrewAI 实现了基于角色的多 Agent 架构：Agent（围绕 LLM 的 Harness，由角色、目标、背景故事和工具定义）、Task（工作单元）、Crew（Agent 集合）。CrewAI 的 Flows 层增加了"在关键处注入智能的确定性骨架"，管理路由和验证，同时 Crew 处理自主协作。 AutoGen（正演化为 Microsoft Agent Framework）开创了对话驱动的编排。其三层架构（Core、AgentChat、Extensions）支持五种编排模式：顺序、并发（扇出/扇入）、群聊、Handoff 和 Magentic（管理 Agent 维护动态任务账本协调专家）。 脚手架隐喻 脚手架隐喻不是装饰性的。它是精确的。 建筑脚手架是临时基础设施，让工人能够建造他们否则无法够到的结构。它不执行建设工作，但没有它，工人无法到达高层。 关键洞察：脚手架在建筑完成后被拆除。 随着模型能力提升，Harness 复杂性应当降低。Manus 在六个月内重构了五次，每次重写都在移除复杂性。复杂的工具定义变成了通用的 shell 执行。"管理 Agent"变成了简单的结构化 Handoff。 这指向了共同演化原则：模型现在在训练后阶段已经将特定 Harness 纳入循环。Claude Code 的模型学习了使用它所训练的特定 Harness。更改工具实现可能会降低性能，因为这种紧耦合关系。 Harness 设计的"面向未来测试"：如果性能随着更强大的模型提升而无需增加 Harness 复杂性，那么设计就是合理的。 定义每个 Harness 的七个决策 每个 Harness 架构师都面临七个选择： 1. 单 Agent vs. 多 Agent Anthropic 和 OpenAI 都说：先最大化单个 Agent 的能力。 多 Agent 系统增加开销（路由需要额外的 LLM 调用、Handoff 过程中丢失上下文）。只有当工具过载超过约10个重叠工具，或存在明显独立的任务领域时才拆分。 2. ReAct vs. 先规划后执行 ReAct 在每一步都交织推理和行动（灵活但每步成本更高）。先规划后执行将规划与执行分离。LLMCompiler 报告比顺序 ReAct 快3.6倍。 3. 上下文窗口管理策略 五种生产级方法：基于时间清除、对话摘要、观察遮蔽、结构化笔记、子 Agent 委派。ACON 研究显示在保持95%以上准确率的同时减少26到54%的 token 消耗，方法是优先保留推理轨迹而非原始工具输出。 4. 验证循环设计 计算性验证（测试、linter）提供确定性的事实依据。推理性验证（LLM 作为评判者）能捕获语义问题但增加延迟。Martin Fowler 的 Thoughtworks 团队将此框架化为引导器（前馈，行动前引导）与传感器（反馈，行动后观察）。 5. 权限和安全架构 宽松模式（快但有风险，自动批准大多数操作）vs. 严格模式（安全但慢，每个操作都需要批准）。选择取决于部署场景。 6. 工具范围策略 更多工具往往意味着更差的性能。Vercel 从 v0 中移除了80%的工具，获得了更好的结果。Claude Code 通过懒加载实现了95%的上下文减少。原则：只暴露当前步骤所需的最小工具集。 7. Harness 厚度 多少逻辑放在 Harness 中 vs. 模型中。Anthropic 押注薄 Harness 和模型改进。基于图的框架押注显式控制。Anthropic 定期从 Claude Code 的 Harness 中删除规划步骤，因为新版本模型已经将该能力内化。 Harness 即产品 使用相同模型的两个产品，仅凭 Harness 设计的不同就能产生截然不同的性能。TerminalBench 的证据很清楚：仅更换 Harness 就让 Agent 的排名跳升了20多个位次。 Harness 既不是已解决的问题，也不是商品层。它是最硬核工程所在之处：将上下文作为稀缺资源来管理、设计在错误级联之前捕获失败的验证循环、构建提供连续性而不产生幻觉的记忆系统、以及在构建多少脚手架与留多少给模型之间做出架构押注。 这个领域正在向更薄的 Harness 演进。但 Harness 本身不会消失。即使是最强大的模型也需要某个东西来管理它的上下文窗口、执行它的工具调用、持久化它的状态、并验证它的工作。 下次你的 Agent 失败时，不要怪模型。看看 Harness。

@foundersfund @halterHQ @peterthiel @Nofence_AS @Gallagher_Group @pudgypenguins @IglooInc @Walmart @PayPal @PalantirTech @stripe 09/ @peterthiel 的「秘密」2026 年版： @PalantirTech——政府不会自己建数据分析系统 @stripe——银行不会为开发者建支付基础设施 @halterhq——没有人认为全球十亿头奶牛是值得数字化的传感器网络 三个领域，被AI改造之前有同一个特征：复杂、低效、没有人认为值得认真做。 这正是他一直在找的地方。

@foundersfund @halterHQ @peterthiel @Nofence_AS @Gallagher_Group @pudgypenguins @IglooInc @Walmart @PayPal @PalantirTech @stripe 8/今天的市场给出了新的背景： 大模型能力平民化，「会用 AI」已经不是护城河。 真正稀缺的只剩一样东西 —— AI 无法凭空生成的专有数据。 @halterhq 60 万头牛的行为数据，任何竞争对手都买不到。

前天据彭博报道，@foundersfund 刚领投了一家给奶牛戴AI项圈的公司 @halterHQ ，pre-money 估值20亿美元，较九个月前翻倍，融资已超额认购。 x.com/business/statu… 彼得·蒂尔 @peterthiel 这回又发现了什么「秘密」？🧵