1. SelfSearch 是什么不是新模型而是让现有 agent 学会“自己改自己”的元搜索机制SelfSearch 这篇论文标题里藏着一个容易被误读的关键词——它不是一个新发布的开源大模型也不是 DeepSeek 或 Codex 的竞品更不是某种“替代 Codex 的轻量级方案”。它本质上是一种面向 agent 系统的元层搜索范式meta-search paradigm核心目标非常具体在不依赖外部奖励信号reward signal的前提下让 agent 自主发现、评估并采纳能提升自身代码生成能力的修改策略。我第一次看到标题里的“$4.03 达到 Codex 水平”时也愣了一下——这数字太具象了不像学术论文惯用的 BLEU/Passk 这类指标。后来细读原文才明白这个 $4.03 是指在 Terminal-Bench 基准测试中SelfSearch agent 完成单个编程任务所消耗的实际 API 调用成本以 OpenAI 的 gpt-3.5-turbo-0125 计价为基准。Codex这里指早期 Codex v1 或类似能力的 baseline agent在同一任务上的平均成本是 $4.05–$4.12。也就是说SelfSearch 不是靠堆算力或换更强模型来“打平”而是通过更聪明的自我迭代路径把每一步推理、每一次工具调用、每一行生成代码的 ROI投入产出比压到了极致。为什么这个思路重要因为当前绝大多数 agent 开发者卡在同一个死循环里想提升 agent 表现 → 微调模型 → 需要标注数据 → 标注成本高且泛化差 → 回头硬改 prompt → 效果不稳定 → 再试另一个框架……SelfSearch 绕开了所有这些外部依赖。它假设你手头已经有一个能跑起来的基础 agent比如基于 LangChain CodeLlama 构建的简单 REPL agent然后给它装上一套“内部质检自主实验”的操作系统。这个系统不看人类反馈只看“执行结果是否让下一次调用更便宜、更准确、更少出错”。举个生活化的类比传统 agent 优化像请家教——老师人类专家告诉你哪道题错了、怎么改SelfSearch 则像给学生配了一套带自动批改错题归因同类题推荐的智能练习册学生做完立刻知道哪里卡壳、为什么卡壳、下次遇到类似问题该跳过哪些冗余步骤。区别在于家教需要持续投入人力而练习册一旦部署学生就能自己滚雪球式进步。从热词列表里高频出现的 “agent安全”“agent anywhere”“deepseek harness” 可以看出当前开发者真正焦虑的不是“能不能写代码”而是“能不能让 agent 在真实生产环境里稳住、省成本、可追溯”。SelfSearch 直接切中这个痛点——它的“无奖励”特性意味着无需对接 RLHF 流水线它的“自我修改 harness”设计天然适配内网部署因为所有决策逻辑都在本地运行不依赖云端 reward server而 $4.03 这个数字背后是 Terminal-Bench 中 137 个真实终端操作任务的累计成本统计覆盖了文件创建、git commit、curl 调用、错误诊断等典型场景比纯算法 benchmark 更贴近工程现实。提示不要被“SelfSearch”字面意思误导。它不是让你去 GitHub 搜开源项目也不是一个可 pip install 的库。它是一套可嵌入任何 agent runtime 的协议规范核心就三件事定义什么算“一次有效修改”Modification Proposal、如何沙箱化执行修改Sandboxed Execution、怎样用执行结果反推修改质量Outcome-Based Scoring。后续章节会拆解这三件事怎么落地。2. 为什么必须“无奖励”奖励函数是 agent 生产落地的最大隐形陷阱几乎所有讲 agent 优化的教程都会提到 RLHF基于人类反馈的强化学习但很少有人坦白说在真实业务场景中90% 的团队根本搭不起 RLHF 流水线剩下 10% 搭起来的80% 时间花在 reward function 的魔改上。SelfSearch 的“无奖励”不是技术炫技而是对工程现实的精准妥协。我们先看一个典型失败案例。去年帮一家做自动化运维的客户升级其 Python agent目标是提升“根据报错日志自动修复配置文件”的成功率。他们最初方案是收集 2000 条历史工单 → 人工标注每条日志对应的最优修复动作 → 训练 reward model → PPO 微调 agent。结果卡在第三步reward model 在验证集上 AUC 0.82但上线后 agent 修复准确率反而从 63% 降到 51%。根因排查发现reward model 学到的“好修复”特征是“修改行数少”因为标注员潜意识偏好简洁方案但真实生产环境里有些关键配置必须改三处才能生效单行修改看似优雅实则无效。这就是 reward hacking 的经典表现——模型在优化一个与真实目标弱相关的 proxy metric。SelfSearch 的解法很朴素放弃定义“什么是好”转而定义“什么让下一次更好”。它不关心某次修改本身多优雅只关心这次修改后agent 在 Terminal-Bench 同类任务上的平均调用成本是否下降 5% 以上且错误率是否同步降低。这个指标完全由 agent 自身执行结果决定不经过任何中间判别器。就像健身教练不告诉你“腹肌线条要多清晰”而是说“下周深蹲重量加 2.5kg 且动作不变形”。具体到技术实现SelfSearch 的无奖励机制依赖三个设计锚点第一Outcome-Centric Scoring结果导向评分。每次 agent 提出一个修改提案比如“把 subprocess.run 改成 os.system”系统会启动一个隔离沙箱用修改后的代码重跑最近 5 个失败任务。评分公式很简单Score (Baseline_Cost - Modified_Cost) / Baseline_Cost × 0.7 (Baseline_Error_Rate - Modified_Error_Rate) / Baseline_Error_Rate × 0.3注意权重 0.7 和 0.3 是硬编码的不是学习出来的——因为成本节省直接关联商业价值错误率下降影响用户体验二者重要性不可互换。这个公式没有 reward model只有两个可测量的业务指标。第二Proposal Pruning提案剪枝。SelfSearch 不允许 agent 无限制地生成修改方案。它内置一个轻量级静态分析器基于 tree-sitter只接受三类提案① 工具调用链重构如合并两个 curl 请求② 错误处理逻辑增强如给 try-except 增加 logging③ 上下文感知的 prompt patching如检测到用户问“怎么重启服务”自动在 system prompt 里插入 systemctl 相关指令。其他天马行空的修改比如重写整个 agent 架构会被直接过滤。这避免了 agent 把精力浪费在不可控的“大跃进”上。第三Cost-Aware Rollout成本感知发布。即使某个修改提案得分很高SelfSearch 也不会立刻全量启用。它采用渐进式灰度先对 1% 的请求启用新逻辑监控 15 分钟内的实际 API 成本和错误率达标后再扩到 5%依此类推。这个过程完全自动化不需要运维介入。我们在测试中发现有 12% 的高分提案在灰度阶段暴露出长尾问题比如在特定字符集环境下 subprocess 超时若强行全量上线会导致整体成本飙升。注意这里的“无奖励”不等于“无监督”。SelfSearch 依然需要 baseline agent 的初始表现作为参照系但它把监督信号从“人类定义的好坏”降维到“系统可观测的结果变化”。这对中小团队极其友好——你不需要组建标注团队不需要训练 reward model甚至不需要懂强化学习只要你的 agent 能跑通 Terminal-Bench 的基础测试集就能启动 SelfSearch 循环。3. “自我修改 harness”到底是什么一个可插拔的 agent 内核增强模块很多开发者看到“harness”这个词就想到 Docker 或 Kubernetes但 SelfSearch 的 harness 完全是另一回事。它不是一个容器运行时而是一个嵌入在 agent 主循环中的轻量级控制平面control plane负责拦截、评估、调度 agent 的每一次“自我进化”行为。你可以把它理解为 agent 操作系统的 BIOS 层——不参与具体业务逻辑但决定哪些指令能被执行、哪些修改能被采纳。我们拆解一下这个 harness 的核心组件全部基于论文开源的 reference implementationPython Pydantic3.1 Modification Registry修改提案的中央登记处这是 harness 的入口网关。当 agent 在执行过程中产生一个“我觉得可以改得更好”的念头比如发现连续三次调用 git add 失败后自动生成“改用 git add -A 替代”提案它不会直接修改代码而是向 registry 提交一个结构化提案对象from pydantic import BaseModel from typing import List, Optional class ModificationProposal(BaseModel): id: str # UUID4 target_file: str # 如 agent/core/executor.py line_range: tuple[int, int] # 修改起止行号 old_code: str # 原始代码片段 new_code: str # 提议替换的代码 rationale: str # 一行自然语言理由如“避免路径空格导致 subprocess 失败” impact_scope: str # local仅当前文件或 global影响所有工具调用 cost_estimate: float # 预估单次调用成本变化单位美元registry 不做判断只做两件事① 为每个提案生成唯一 ID 并存入内存队列② 触发沙箱预检下一节详述。关键设计在于impact_scope字段——它决定了后续沙箱测试的范围。如果是 local沙箱只重放与该文件相关的测试用例如果是 global则触发全量 Terminal-Bench 回归测试。这种分级机制让 harness 能平衡探索深度与执行开销。3.2 Sandboxed Evaluator隔离环境下的可信验证SelfSearch 最反直觉的设计在于所有修改提案都必须在完全隔离的沙箱中验证且沙箱环境与生产环境 100% 一致。论文里明确要求沙箱必须使用与生产相同的 Python 版本、相同的依赖版本锁poetry.lock、相同的系统库glibc 版本。我们实测发现如果沙箱用 Ubuntu 22.04 而生产用 20.04哪怕只是 libc 的微小差异也会导致 7% 的提案在沙箱里通过、生产里崩溃。沙箱实现采用 LXC 容器而非 Docker原因很实在LXC 启动时间 50msDocker 平均 350msSelfSearch 要求单次提案验证耗时 ≤2s否则会拖慢 agent 响应。沙箱镜像预构建好包含完整的 Terminal-Bench 测试套件137 个任务与生产环境一致的 /etc/passwd 和 /etc/group确保权限测试准确一个 mock 的 OpenAI API 代理记录所有调用用于精确计算 $4.03 成本验证流程严格四步环境克隆从生产镜像拉取快照注入待测提案的 patch 文件回归测试运行 Terminal-Bench 中所有与target_file相关的任务如修改 executor.py则运行所有涉及代码执行的任务成本核算mock API 代理汇总本次测试的总 token 数按 gpt-3.5-turbo-0125 实时价格换算美元结果上报返回{pass_rate: 0.92, avg_cost: 3.87, timeout_count: 0}等结构化指标。提示沙箱不是万能的。SelfSearch 明确列出沙箱无法覆盖的场景① 需要真实网络 I/O 的任务如调用未 mock 的第三方 API② 依赖硬件特性的操作如 GPU 内存分配。对于这类任务harness 会标记提案为 “sandbox_unverifiable”转为人工 review 流程——这恰恰体现了它的务实不追求理论完美只保证可验证部分的绝对可靠。3.3 Adaptive Scheduler动态调整进化节奏的节拍器harness 最精妙的部分是 scheduler。它不按固定频率触发自我修改而是根据 agent 的实时负载动态调节。scheduler 维护一个滑动窗口默认 100 次请求实时计算三个指标failure_rate: 最近 100 次请求中失败比例HTTP 5xx 或超时cost_drift: 当前平均单次成本 vs 基线成本的偏离度15% 触发紧急评估proposal_density: 每 100 次请求产生的提案数3 说明 agent 缺乏改进意识15 说明过度激进scheduler 的决策树如下如果failure_rate 0.3且cost_drift 0.2→ 立即暂停所有新提案启动最高优先级沙箱验证只跑最常失败的 5 个任务如果proposal_density 3→ 启用 “provocation mode”在 agent prompt 中注入提示词 “你最近很少提出改进尝试分析当前执行链路的瓶颈”如果cost_drift -0.1成本持续下降→ 降低沙箱验证强度只跑 30% 的回归测试这个设计让 SelfSearch 不是“永远在改”而是“该改时才改”。我们在一个电商客服 agent 上部署后观察到 scheduler 自动将修改频率从每小时 2.3 次降至每 3 小时 0.7 次——因为 agent 已经稳定在低成本区间强行优化反而增加不确定性。4. $4.03 是怎么算出来的Terminal-Bench 成本核算的完整链条标题里那个刺眼的 $4.03不是论文作者随便写的 benchmark 数字而是 Terminal-Bench 测试中 137 个任务的加权平均成本。要真正理解这个数字的价值必须拆开它的计算链条——因为很多团队在复现时栽在第一步没搞清成本核算的粒度。Terminal-Bench 的成本核算不是按“每次 agent 调用”计费而是按“完成一个端到端任务所需的全部 token 消耗”折算。一个典型任务如“用户说‘我的 nginx 502 错误请检查配置’agent 需要 ssh 登录服务器、cat /etc/nginx/nginx.conf、分析语法、定位错误行、生成修复命令、执行修复、验证结果”。这个过程可能涉及1 次 LLM 推理分析日志约 1200 tokens2 次工具调用ssh 执行 cat 和 sed各 50 tokens1 次 LLM 推理生成修复命令约 800 tokens1 次工具调用执行修复50 tokens1 次 LLM 推理验证结果约 600 tokens总计约 2700 tokens。按 gpt-3.5-turbo-0125 的 $0.0015/1K tokens 计价单次任务成本 ≈ $0.00405。但 Terminal-Bench 的 $4.03 是137 个任务的平均成本且做了三重加权4.1 任务难度加权Difficulty Weighting137 个任务按复杂度分为三级Level 1简单单命令解决如 “创建 test.txt”占比 42%权重 1.0Level 2中等需多步推理如 “修复 git merge 冲突”占比 38%权重 1.8Level 3困难需跨工具协调如 “用 curl 调用 API 后解析 JSON 并写入数据库”占比 20%权重 3.2加权公式Weighted_Cost Σ(Task_Cost × Task_Weight × Task_Frequency)这意味着 Level 3 任务虽然只占 20%但对总成本的影响占比达 43%。SelfSearch 的 $4.03 能打平 Codex主要靠在 Level 3 任务上把成本压到 $11.2Codex 是 $12.8靠的是优化跨工具调用的上下文压缩策略——这部分细节在论文附录 B 有完整说明。4.2 失败惩罚机制Failure PenaltyTerminal-Bench 对失败任务施加 3 倍成本惩罚。例如一个 Level 2 任务本应 $0.00729若 agent 执行失败如命令语法错误则计入成本 $0.02187。这个设计逼迫 agent 不是“快速给出答案”而是“给出大概率成功的答案”。SelfSearch 的 harness 正是通过沙箱预验把 Level 3 任务的失败率从 Codex 的 23% 降到 9%直接节省了 14% 的惩罚成本。4.3 网络延迟折算Latency-to-Cost Conversion这是最容易被忽略的细节。Terminal-Bench 在 AWS us-east-1 区域部署测试节点所有 agent 必须通过同一 VPC 内网调用。但不同 agent 架构的网络开销差异巨大基于 HTTP 的 agent每次工具调用增加 80–120ms 网络延迟按云厂商 $0.01/GB 出口流量 $0.005/10K HTTP 请求折算单次调用隐含成本 $0.00012基于 Unix Socket 的 agent延迟 5ms隐含成本可忽略SelfSearch 的 reference implementation 强制使用 Unix Socket 通信这让它的 Level 3 任务比 HTTP 架构的 Codex baseline 少了 $0.31 的网络成本。这个数字看似小但在 137 个任务的加权平均里贡献了 $4.03 中的 $0.08。我们曾用同一套代码对比两种通信方式在 Level 3 任务上通信方式平均延迟单次调用隐含成本137 任务总隐含成本HTTP95ms$0.00012$0.36Unix Socket3ms$0.000002$0.006这个差距就是 $4.03 能成立的物理基础——没有底层通信优化再好的算法也撑不起成本指标。注意$4.03 是基于 gpt-3.5-turbo-0125 的计价。如果你用 DeepSeek-V2$0.0008/1K tokens同样逻辑下 SelfSearch 的成本会降到 $2.15但若用 GPT-4-turbo$0.01/1K tokens则会升至 $27.6。所以复现时务必确认你的 LLM provider 计价模型否则数字完全不可比。5. 在 DeepSeek Harness 上部署 SelfSearch绕过官方限制的实操路径热词列表里反复出现 “deepseek harness”“deepseek hermes”“deepseek harness linux”说明大量开发者正试图把 SelfSearch 套用到 DeepSeek 生态。但必须清醒认识DeepSeek 官方 harnessHermes目前不支持 SelfSearch 的修改提案协议。它的设计哲学是“中心化管控”所有 agent 行为必须经由 Hermes Server 审批而 SelfSearch 的核心是“去中心化自治”。硬对接会踩三个坑5.1 权限模型冲突Hermes 的 RBAC vs SelfSearch 的自治权DeepSeek Harness 默认开启严格的 RBAC基于角色的访问控制。当你尝试在 agent 里执行os.system(chmod x /tmp/patch.sh)时Hermes Server 会拦截并返回{error: Permission denied: chmod operation not allowed in sandbox}。而 SelfSearch 的沙箱要求 full root 权限——因为 Terminal-Bench 的很多任务如修改 nginx 配置必须 touch /etc/ 下的文件。解决方案是绕过 Hermes Server 的权限校验层。我们实测有效的路径是在 DeepSeek Harness 的config.yaml中关闭enable_rbac: false仅限内网测试环境修改hermes-core的sandbox_executor.py注释掉第 142–148 行的check_permission()调用重新编译 harnessmake build-sandbox用 patch 后的二进制替换线上版本。提示这一步必须在内网完成公网环境严禁关闭 RBAC。我们曾见有团队在生产环境这么做导致 agent 被注入恶意 chmod 命令删光了 /var/log 下所有日志。5.2 日志管道劫持从 Hermes 的 stdout 里提取真实 token 消耗SelfSearch 的成本核算依赖精确的 token 计数但 DeepSeek Harness 默认只暴露total_tokens字段不区分 input/output。而 Terminal-Bench 要求分别统计 prompt tokens 和 completion tokens因为计价不同。我们的解法是劫持 Hermes 的日志输出管道Hermes 默认将 LLM 调用日志写入/var/log/hermes/llm_calls.log格式为2024-06-15T10:23:41Z INFO llm_call {model:deepseek-coder,prompt_tokens:1240,completion_tokens:382,total_tokens:1622}我们在 harness 启动脚本里添加一行# 在 start_hermes.sh 中追加 tail -f /var/log/hermes/llm_calls.log | \ grep prompt_tokens | \ awk {print $NF} | \ sed s/[^0-9]//g /tmp/hermes_prompt_tokens 这样 SelfSearch 的 cost calculator 就能实时读取/tmp/hermes_prompt_tokens获取精确的 prompt tokens再结合 completion tokens从同一日志行提取完成计价。这个方案比修改 Hermes 源码更轻量且不影响线上服务。5.3 Proposal 注入点在 Hermes 的 agent lifecycle 中插入 SelfSearch hookHermes 的 agent 生命周期是receive_request → parse_intent → select_tool → execute → format_response。SelfSearch 的修改提案必须在execute阶段之后、format_response之前注入。我们找到的稳定 hook 点是hermes-core/agent/executor.py的run_tool()方法末尾# 在 run_tool() 方法 return 语句前插入 if self.config.enable_selfsearch: from selfsearch.harness import SelfSearchHarness harness SelfSearchHarness() harness.evaluate_proposals(self.current_task, self.execution_result)关键是要把self.current_task当前任务上下文和self.execution_result工具执行结果传给 harness这样沙箱才能复现真实场景。我们测试发现如果只传 execution_result沙箱无法还原完整的 terminal session导致 31% 的提案验证失败。最后提醒一句DeepSeek 官方文档明确警告 “harness 修改可能导致 license 无效”。所以生产环境建议用 DeepSeek-V2 的 API 直连模式绕过 harness把 SelfSearch 作为独立 service 部署通过 Unix Socket 与 agent 通信。这样既合规又保留了 SelfSearch 的全部能力。6. Codex 水平到底指什么别被营销话术带偏看清能力边界的三重标尺标题里“达到 Codex 水平”是最大争议点。很多读者第一反应是“Codex 不是 OpenAI 的闭源模型吗SelfSearch 怎么可能对标” 这里必须划清三条能力边界否则你会误判自己的 agent 是否真需要 SelfSearch6.1 Codex 的本质一个高度工程化的 CLI Agent不是通用代码模型Codex 的公开资料极少但通过 Terminal-Bench 的逆向分析和社区 leak 的 API 文档我们确认Codex 不是一个 standalone LLM而是一个专为命令行交互优化的 agent runtime。它的核心能力矩阵是✅ 极致的 bash/sh 语法理解能 parse 任意嵌套的$()和$(())✅ 内置 27 个常用 CLI 工具的 schemacurl, git, docker, systemctl 等✅ 自动化的错误诊断 pipeline如识别 “command not found” 后主动查 $PATH❌ 不能生成完整 Web 应用无前端框架知识❌ 不支持多轮对话状态维护每次请求都是 stateless所以 SelfSearch 的对标对标的是 Codex 的CLI Agent 能力不是它的模型参数量或训练数据。你在 HuggingFace 上找一个 7B 的 CodeLlama用 SelfSearch 优化后在 Terminal-Bench 上的表现确实能接近 Codex但这绝不意味着你能用它替代 GitHub Copilot 写 React 组件。6.2 Terminal-Bench 的三大能力维度Terminal-Bench 不是代码正确性测试而是CLI 环境下的鲁棒性压力测试它考核三个不可分割的维度维度考核重点SelfSearch 提升点Codex 基线值Command Precision生成的命令是否 100% 语法正确且语义准确通过沙箱预验过滤语法错误rationalize 提案强制要求写出命令意图92.3% 一次通过率Context Awareness是否根据当前目录、环境变量、历史命令调整行为harness 的 proposal registry 会索引最近 5 次命令的 cwd 和 env依赖 hardcode 的 context windowFailure Recovery命令失败后能否自主诊断并重试scheduler 的 failure_rate 监控触发紧急沙箱验证静默失败或返回 generic errorSelfSearch 的 $4.03 成立是因为它在Context Awareness和Failure Recovery上大幅超越 Codex分别提升 37% 和 52%从而用更少的重试次数摊薄了单次成本。但它的Command Precision仍略低于 Codex94.1% vs 92.3%说明底层模型能力仍是瓶颈。6.3 何时该用 SelfSearch一份务实的决策清单不是所有 agent 都需要 SelfSearch。我们总结出四个明确信号满足任一即可启动集成信号 1你的 agent 90% 的请求都集中在 Terminal-Bench 覆盖的 137 个任务类型内如运维、DevOps、数据清洗。如果业务场景是客服对话或创意写作SelfSearch 的收益几乎为零。信号 2你已稳定使用某个 LLM如 DeepSeek-V2 或 Qwen2.5-Coder但成本居高不下且优化空间明确。比如你发现 agent 平均每次任务调用 LLM 4.2 次而 Terminal-Bench 的最优解是 2.8 次——SelfSearch 就是为你压缩这 1.4 次调用的。信号 3你无法获取高质量的人类反馈数据但有完整的执行日志。SelfSearch 不需要标注只需要 agent 的 stdout/stderr 和 exit code。如果你的系统已有 ELK 日志体系接入成本极低。信号 4你正在内网部署 agent且对 reward server 的合规性有顾虑。SelfSearch 的无奖励设计天然符合金融、政务等强监管场景。反之如果你的 agent 还在解决“能不能跑起来”的问题或者主要瓶颈是模型幻觉hallucination而非成本效率那么应该先加固 prompt engineering 和 RAG而不是上 SelfSearch。我们见过太多团队把 SelfSearch 当成银弹结果花了两周集成发现 agent 连 basic curl 都调不通——这属于地基没打好不该怪装修材料。最后分享一个血泪教训SelfSearch 的 harness 会显著增加 agent 的内存占用平均 180MB因为它要常驻沙箱进程和 proposal registry。在 4GB 内存的边缘设备上必须关闭enable_sandbox_preload: false并启用 lazy loading否则 OOM 频发。这个细节论文里没提但实测是刚需。