echoVic

@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 ，谢谢。

@sentinelK 现在没有统一的量化指标，大家都只看结果，结果是通过完整链路体现的，比如任务完成率、能自主推进多少轮、工具调用是否稳定、上下文管理、权限/可观测性、验证命令通过率、陈本和耗时。

这些 feature 不是为了堆功能，而是在提高“可交付任务”的成功率。coding 是最好的切口，因为结果可验证：代码能不能跑、测试过没过、diff 改了什么都很清楚。再往后我觉得会从 coding 走向 work ，各家抢这个领域，本质上也是在抢真实任务闭环和数据飞轮。

插一句，好不好用其实也主观，cc 和 codex 不也是口碑不断交替

@jiechen257 暂时不想动

@waterwawa 欢迎使用、讨论