echoVic

@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 版