@iwolfor runtime 我再打磨打磨，然后再支持 Windows

如果你有客户，先找一些上游接一下跑起来。号池这个重要但也没那么重要，是否有客户更重要，而且最好是 B 端客户

@dkhcyx 大趋势 agent 还是属于各大模型厂商，但等他出来再看吧，如果做得好，三方也会有出路

@utodea 是的，一起努力，加油

@TArysiyehua benchmark 确实还没有，标准集（ SWE-bench 这类）不太适合 Orca 这种 goal 模式跑几十轮的场景，后面会找几个典型任务录完整过程。

目前收到不少人说比 codewhale 好用，这对我来说比跑分更有参考价值。欢迎你也试试，有具体对比场景的话可以聊。

@FrankAdler 这个项目发起其实比较早，当时 ds 还没铺天盖地的消息。从另一个角度来说，我想验证我自己这套全自动化的流程

@sentinelK 嗯嗯，所以从研发流程这里我是质量门禁先行，然后再开发。agent 设计部分就是一定要有 verifier

@zbinlin 上个月家里那台电脑消耗 200 多亿 token

@Rorysky 举个例子，Provider 层专门处理 deepseek 的 SSE 流式输出，把 reasoning delta 、content delta 、tool_call 做成稳定事件；上下文按 deepseek V4 的长上下文做窗口管理和自动压缩；模型上有 auto 路由，主循环偏 Pro ，辅助任务/subagent 偏 Flash ，用速度和成本做取舍。

可以试试 orca-agent ，专为 deepseek 设计的 agent 。https://orcaagent.dev

我也写了一篇，欢迎交流
https://echovic.com/blog/ai/loop-engineering-essence

@ychost
1. 我自己的 Orca Agent 在 DeepSeek 上用 immutable prefix + append-only log 做上下文分层，缓存命中率 90%+。如果不做管理，同样的任务链跑到第 5 步就开始漂移——不是模型变笨了，是上下文被污染了。详见文章： https://mp.weixin.qq.com/s/1CDceJGRU5TdUwhKkj33cA?scene=1

2. ICLR 2026 发表的 ACE 论文（ Stanford + SambaNova ）专门研究 Agent 的上下文工程，结论是：不做结构化上下文管理的 Agent 会出现 "context collapse"——随着对话轮次增加，关键信息被压缩丢失，性能断崖式下跌。做了 ACE 上下文管理的 Agent 比 baseline 高 10.6% 。这不是往上下文里"注入"什么，是防止有效信息被稀释掉。详见： https://openreview.net/pdf/41517b8de1ef2f21f3d8f41c0e792e8ebe626e08.pdf

3. OpenAI 2025 年 11 月发布的 GPT-5.1-Codex-Max 技术文档原文："它会修剪历史记录，同时保留长期推理所需的关键上下文。在 Codex 中，模型接近上下文窗口上限时会自动执行压缩，取得新的上下文窗口并继续处理任务。"——这就是 harness 层在做上下文管理，不是模型自己在管。 详见： https://openai.com/zh-Hant/index/gpt-5-1-codex-max/

4. Particula 今年 3 月的分析：六个前沿模型在 SWE-bench Verified 上得分互差不超过 0.8 个百分点 （ 80.2%–80.9%），模型之间已经没有区分度。但同一个 Claude Opus 4.5 ，换不同 scaffold 在 SWE-bench Pro 上得分从 45.9%（ SEAL ）到 55.4%（ Claude Code ）， 差了 9.5 个百分点 。更极端案例：仅改 harness ，同一 LLM 从 42% 到 78%。

而且 Meta + Harvard 的 Confucius Agent 用 更弱的 Sonnet 4.5 配自研 scaffold （ 52.7%）打败了用 Anthropic 官方 scaffold 的 Opus 4.5 （ 52.0%）。弱模型 + 好 harness > 强模型 + 弱 harness 。详见： https://particula.tech/blog/agent-scaffolding-beats-model-upgrades-swe-bench

随便查查就有大量论证的论文和资料。

@ychost 还是那句话，模型负责能力上限，harness 负责把能力变成稳定交付。

1. 上下文管理的核心是控制什么不进入上下文。就算 1M 上下文窗口，无关信息堆进去只会稀释注意力、导致任务漂移，模型不会自己决定忘什么，这就是 harness 在做的事。

2. 你说的"升级模型后拆掉旧补丁效果更好"，说明旧 harness 在补偿模型短板，模型进步了 workaround 该拆。但拆补丁本身就是 harness 迭代，不是"harness 没用"。引擎强了拆涡轮，不代表变速箱从来没用。

3. 沙箱隔离、文件快照、超时熔断，这些本来就不往 prompt 里注入，它们是执行层基础设施。把 harness 理解成"往上下文塞字"，是把操作系统理解成了开机画面。

@wfhtqp 有搞头，不过我可能不会直接做消息编号列表，而是做成 context_refs 。

主代理只说子代理需要哪段上下文，runtime 自动解析 transcript 、去重、必要时摘要，并尽量把共享前缀稳定下来吃缓存。裸编号在 compact/resume/fork 后容易漂，得用稳定 id 或 range 。

这个我记一下，挺适合放到子代理上下文隔离这块。

@ychost 你是从哪儿判断这些工程上的实现不会影响到 agent 效果的？那如果这样直接跑裸模型不就行了

@ychost 恰恰相反，Codex 的 harness 一点都不简单。它有沙箱隔离、网络策略、文件系统快照回滚、超时空之、多步验证循环。

举个例子，/goal 这个命令背后就是一整套 harness 的落地——它不是简单地把你的需求丢给模型，而是由 harness 负责拆解任务、管理多步执行状态、在每一步做验证和回滚决策。

你觉得"没那么多 harness 约束"，只是因为 OpenAI 把复杂性藏在了交互界面后面。

@zj 有这个计划，还有 app 版

@ychost 模型负责能力上限，harness 负责把能力变成稳定交付。

如果只是很薄的一层 prompt/skill 包装，那确实价值有限。但我理解做在 agent 里的 harness 不只是 prompt ，还有上下文管理、工具治理、权限、可观测性、失败恢复、验证收尾和成本控制。模型越强，上限越高； harness 做得越扎实，能力越能稳定落到真实任务里。

@visper reasonix 我也关注过，它确实是 deepseek 里做得比较早、也比较有代表性的一个，，尤其是高缓存命中这块做得很有意思，我还参考了它的方案优化了 orca 的缓存： https://mp.weixin.qq.com/s/1CDceJGRU5TdUwhKkj33cA?scene=1

交互确实很关键，agent 如果只给最后结果，中间过程完全不可见，用户很难建立信任。所以做 Orca 之前我就在想，应该尽量把 reasoning 、工具调用、diff 、验证这些完整过程展示出来，后面也会继续参考一些优秀产品的交互。

同一个 deepseek ，外层 harness 做得不一样，最后稳定性、缓存命中、可控性都会差很多。所以我也不觉得谁一定替代谁，更多是不同取舍。你如果后面试 Orca ，欢迎直接提 issue ，谢谢。