mirror of
https://github.com/deepseek-ai/awesome-deepseek-agent.git
synced 2026-11-05 01:07:37 +00:00
[GH-ISSUE #258] 自荐 Orcana：一个约束优先的 DeepSeek-native Coding Agent runtime #98
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/awesome-deepseek-agent#98
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Leo-Ayh-Oday on GitHub (Jun 27, 2026).
Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-agent/issues/258
刚提交了 guide PR（#257）。
https://github.com/Leo-Ayh-Oday/deepseek-orcana
Orcana 的核心问题是：当 LLM 能读代码、改文件、执行命令并持续工作多轮时，
runtime 应该怎么约束它，而不是靠 prompt 建议？
几个设计方向——
目前 v0.2.1，10 Phase / 32 PR / 17 验收标准收口中。
如果你也在做 Agent runtime 或约束引擎，欢迎看看指出设计问题。
@Leo-Ayh-Oday commented on GitHub (Jun 27, 2026):
@qwas982 感谢反馈。我理解你的意思,要找到一个数字上与物理上的约束，作为外部独立/隔离的存在，供大模型使用。
这个观点我认同，而且这也是 Orcana 目前在尝试做的方向。
我不太想把 Orcana 做成“人类写一堆 prompt 去编排模型”的 agent proxy。我的目标更接近：让模型在一个外部 runtime 约束层里工作，关键状态由 runtime 判断，而不是由模型自述判断。
几个具体例子：
PlanValidator/TaskPacket：计划不是模型说“我有计划”就通过，而是要过结构校验，比如 node、scope、done criteria、verification 等。PatchTransaction：写文件不是模型说“改好了”就算，而是要有 base hash、diff、scope、verification 和 rollback 语义。EvidenceLedger：完成不是模型说“测试通过”，而是必须有真实的 typecheck / test / build / manual evidence。Completion Gates：最终能不能结束，不读模型自信程度，而是读 runtime state。Sandbox / Hooks / Permission：工具调用不完全交给模型自由决定，而是放在外部权限和执行约束里。Flash Judge：这部分不是数学约束，它仍然是模型判断，所以我只把它当作 independent evaluator，不把它当成硬安全边界。所以你说的“底层约束”我觉得是对的。Orcana 现在还很早期，不敢说已经解决了这个问题，但它确实不是想继续走“网页 demo / 人工 prompt 编排”的路线，而是想把 coding agent 做成一个 constraint-first runtime。
如果你愿意展开，我更想听你说的“数字/物理约束”具体指哪类东西：OS sandbox、deterministic execution、capability-based tool protocol、compiler/typechecker/test harness，还是一种更底层的 agent-tool architecture？这些建议对我后面改 Orcana 很有价值。
@easlie114514 commented on GitHub (Jun 27, 2026):
你好，请不要理会这个qwas982，他应该是个”喷子“，在我的issue中留下了一模一样的评论。另外，你的项目方向看起来挺不错。
@Leo-Ayh-Oday commented on GitHub (Jun 27, 2026):
谢谢你，欢迎测试我的项目，只是tui做的不好看，但是会慢慢改进。
@.***
---原始邮件---
发件人: @.>
发送时间: 2026年6月27日(周六) 晚上11:05
收件人: @.>;
抄送: "Leo Ahy @.@.>;
主题: Re: [deepseek-ai/awesome-deepseek-agent] 自荐 Orcana：一个约束优先的 DeepSeek-native Coding Agent runtime (Issue #258)
easlie114514 left a comment (deepseek-ai/awesome-deepseek-agent#258)
@qwas982 感谢反馈。我理解你的意思,要找到一个数字上与物理上的约束，作为外部独立/隔离的存在，供大模型使用。
这个观点我认同，而且这也是 Orcana 目前在尝试做的方向。
我不太想把 Orcana 做成“人类写一堆 prompt 去编排模型”的 agent proxy。我的目标更接近：让模型在一个外部 runtime 约束层里工作，关键状态由 runtime 判断，而不是由模型自述判断。
几个具体例子：
PlanValidator / TaskPacket：计划不是模型说“我有计划”就通过，而是要过结构校验，比如 node、scope、done criteria、verification 等。
PatchTransaction：写文件不是模型说“改好了”就算，而是要有 base hash、diff、scope、verification 和 rollback 语义。
EvidenceLedger：完成不是模型说“测试通过”，而是必须有真实的 typecheck / test / build / manual evidence。
Completion Gates：最终能不能结束，不读模型自信程度，而是读 runtime state。
Sandbox / Hooks / Permission：工具调用不完全交给模型自由决定，而是放在外部权限和执行约束里。
Flash Judge：这部分不是数学约束，它仍然是模型判断，所以我只把它当作 independent evaluator，不把它当成硬安全边界。
所以你说的“底层约束”我觉得是对的。Orcana 现在还很早期，不敢说已经解决了这个问题，但它确实不是想继续走“网页 demo / 人工 prompt 编排”的路线，而是想把 coding agent 做成一个 constraint-first runtime。
如果你愿意展开，我更想听你说的“数字/物理约束”具体指哪类东西：OS sandbox、deterministic execution、capability-based tool protocol、compiler/typechecker/test harness，还是一种更底层的 agent-tool architecture？这些建议对我后面改 Orcana 很有价值。
你好，请不要理会这个qwas982，他应该是个”喷子“，在我的issue中留下了一模一样的评论。另外，你的项目方向看起来挺不错。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.Message ID: @.***>
@Leo-Ayh-Oday commented on GitHub (Jun 29, 2026):
@qwas982 我理解你的理念 同时我也看了你其他的技术理念 我发现你的理想确实很值得思考 但是同时很多地方也需要重新评估 太过理想化 你现在给我发的这几个我也同意一部分 想要解决模型幻觉 在目前来说还是很难的 他还是按照概率来 导致他很难创造 只能利用现有知识 对于某些专业人士来说 模型能力在他们前面都是小儿科 我想做的就是创造 我之前也设计过一个智能体认知架构 我叫他CCA架构 我看重深度思考 不局限于人类所说的需求 相当于达到一个超预期结果 但是同时也要参考历史经验 不过最大的缺陷依然是模型的问题 无法避免 带来了强大的能力的同时也带来了许多的坑点 后来我了解了递归自进化和涌现行为 我的CCA架构归根也算是个涌现行为的系统 现在我从小做起 先做一个编码的强单智能体 为自己的理想而去奋斗 你说的很多物理类知识我并不是很了解 但是肯定会有研究价值 我拆解了你在其他issues里留下的评论 想要将他工程化对于一个普通人来说太艰难了 一开始还以为你是为了宣传你的智能体或是什么 现在看来 你的想法适合投递到大厂用于借鉴和参考 但是可以实现的那一部分可以再谈一谈 你可能想再次定义一种新的智能体?
你其实把约束分成了三层：
这个区分我认同。尤其是你说 skill / md 文档不是硬约束，这点我也同意。Orcana 里我不会把 skill 当成安全边界，skill 只是指导；真正的约束应该来自 runtime：schema validator、ToolPolicy、Permission、Sandbox、PatchTransaction、EvidenceLedger、CompletionGate、Replay/Rewind。
不过我也想把边界说清楚：Orcana 当前是 API-based Coding Agent Runtime，不是本地推理框架。所以它现在不能直接改 DeepSeek 的 embedding、hidden states 或 KV cache。Embedding 拼接、浅层注入、每层偏置注入、KV guidance 这些需要本地模型权重和推理框架控制权，比如 forward hook / attention cache access。
所以我现在更现实的路线是两层：
第一层，当前主线：
把外部约束做成模型外的 constraint substrate。也就是 TaskState、PatchState、EvidenceState、RiskState、ToolState、ContextState 这些结构化状态。模型可以读取 compact state capsule，但最终能不能执行、能不能完成，由 runtime gate 判断。
第二层，未来研究支线：
如果后面接本地开源模型，可以尝试 Manifold State Adapter：把外部状态张量投影成 soft prompt / prefix / virtual KV / activation steering vector，用来做更强的 model-internal constraint。
也就是说，我认同你说的“仅靠 md 文档和 prompt 不够”。Orcana 现在想做的是先把软件工程世界里的外部约束基座做实：schema、state、capability、transaction、evidence、recovery。等这个基座稳定，再考虑更底层的 embedding / KV / activation 注入。
如果你愿意，我想继续请教一个更具体的问题：你说的外部流形如果先落到 coding agent，而不是物理机器人，它最应该编码哪些状态？
比如：
文件修改风险？
测试失败梯度？
任务到完成状态的距离？
代码影响面曲率？
工具调用风险场？
上下文污染程度？
这些如果能定义成数值状态，我就可以先把它们接进 Orcana 的 GateProfileRouter 和 Evidence/Completion 系统里。
同时我还想说一个有趣的点 今天刷到了关于人的视频 让我不经意联想到我的智能体:Orcana. 他说你的意识和你的大脑 究竟是谁在控制你 有时候我觉得我像个多模态大模型一样 而大脑就如同一整个约束机制(包含身体的各个器官等 因为你也无法精确控制你身体 例如分泌某种激素 控制心脏是否跳动 都像是硬约束) 我的生活就像在自我进化 不停的学习 越想越让我觉得 科技发展到最后 会不会回归原始 可能我们研究的东西一开始就有了呢.再次谢谢你的评论.
@hesam-oxe commented on GitHub (Jul 1, 2026):
@qwas982 你说的外部流形理论非常有深度。但我有一个更激进的提议：
如果“数字脊椎”还不够呢？
碳基生物不仅有脊椎，还有：
外部流形计算引擎是“脊椎”，但 Orcana 想做的是“完整的数字神经系统”。
你提到微分流形、黎曼曲率、测地线距离——这些都是连续的数学结构。
但代码世界是离散的：AST、Control Flow、Type System。
问题：如何用连续的流形结构去约束离散的程序空间？
我认为答案在 Information Geometry：
你提到的“用 PyTorch 张量系统建造外部流形”很有启发。
如果能把代码的 TypeCheck/Test/Build 结果编码成张量，
然后用 Riemannian SGD 在约束流形上做优化，
或许就能实现你所说的“物理与数学的硬约束”。
期待你的进一步推演。🐉☯️
@Leo-Ayh-Oday commented on GitHub (Jul 2, 2026):
@hesam-oxe 你这个对我的涟漪系统有很大的启发 也就是对我的Ripple Engine 很有启发
我现在的 Ripple Engine 主要是：
符号变化
调用方扫描
TypeChecker verify
影响面 obligations
看了你的想法 我觉得 Ripple 可以升级成：
Impact Geometry
也就是不只问：
谁被影响了？
还问：
影响有多大？
影响是否扩散？
影响是否集中在某个局部？
是否出现高曲率区域？
这里的“曲率”可以先工程化为：
impact_curvature =
新增 obligations 数量 / 修改文件数量
例如：
改 1 个函数，引发 30 个 callsites + 8 个测试失败
→ 高曲率
改 1 个局部变量，只影响 1 个测试
→ 低曲率
这就把“代码影响面曲率”落地了。
当然 我还有其他想说的 我理解你的意思是：代码本身是离散的，AST、CFG、Type System、Call Graph 都不是天然连续流形；所以不能直接把微分流形套到代码上。中间需要一个 CodeState 表征层，把代码状态、测试结果、类型检查、影响面、patch diff、上下文污染等编码成向量或分布，再在这个状态空间里定义距离、漂移和曲率。
我理解你的意思是：代码本身是离散的，AST、CFG、Type System、Call Graph 都不是天然连续流形；所以不能直接把微分流形套到代码上。中间需要一个 CodeState 表征层，把代码状态、测试结果、类型检查、影响面、patch diff、上下文污染等编码成向量或分布，再在这个状态空间里定义距离、漂移和曲率。
我比较认同这个方向，但我会稍微修正一点：EvidenceLedger 本身还不能直接等同于 empirical Fisher。它更像经验观测采样层，记录 typecheck/test/build/manual evidence。Fisher / KL / curvature 应该建立在这些观测样本之上，用来估计 patch 对系统状态的敏感度和语义漂移。
对 Orcana 来说，我现在更倾向于先做一个工程版 Code State Geometry，而不是直接做完整 Riemannian SGD：
这样 Orcana 的 EvidenceLedger、Ripple Engine、PatchTransaction、ContextEpoch 就可以变成“数字神经系统”的传感器和反馈回路。
长期如果接本地小模型，再考虑把 CodeStateVector 投影成 soft prefix / virtual KV / activation steering；但当前 API-based runtime 阶段，最现实的是先把这些几何指标接进 GateProfileRouter、SelfRevisionOrchestrator 和 CompletionGate。
@qwas982 同时谢谢你的评论 这次我更加了解了 跟我的想法很像 模型负责思考 这个方向和我对 Orcana 的想法有一部分是相通的。
我现在对 Orcana 的定位不是“让模型直接动手”，而是先让模型在 runtime 约束里把事情想清楚，再进入执行。模型负责意手”，而是先让模型在 runtime 约束里把图、推理和方案生成；Orcana runtime 负责约束、验证、权限、证据和回滚。
我认为长任务里最重要的不是一上来写代码，而是先完成一个高质量的思考与推演流程：
我想把这个做成 Orcana 的一个独立高质量模式，比如 Deep Work Mode / Deep Harness Mode。它不是默认开启，因为它会更慢、更贵；但当用户明确需要“高质量、不追求效率、完整推演”的时候启用。
这个模式里，Orcana 不只是让模型多输出 thinking，而是会产出结构化 artifact：
我觉得这和你说的“数字脊椎”有相似点：模型不是自由乱跑，而是在外部约束轨道里思考和行动。
另外按照你上面的想法 我觉得可以做两个阶段
第一阶段，Orcana 当前主线不会直接做完整的微分流形 / 黎曼流形引擎，因为 Orcana 现在是 API-based Coding Agent Runtime，不能访问 DeepSeek 云端模型的 embedding、hidden states 或 KV cache。所以我会先做模型外部的 Constraint Spine，也就是软件工程版本的“数字脊椎”。
在 coding agent 里，我会先把这些状态数值化：
这些状态会先进入 Orcana runtime，而不是直接注入模型内部：
也就是说，模型可以读取 compact state capsule，但最终能不能执行、能不能完成，不由模型自述决定，而由 runtime constraint 决定。
第二阶段，如果后面接本地小模型，比如 1B / 3B / 7B coder model，我会把这个方向作为研究支线继续探索：
你说的“本地小模型 + 外部流形计算引擎”确实很诱人，因为它可以让小模型不完全依赖自身知识，而是被外部约束轨道校正。但我认为在 coding agent 里，第一步应该先证明这些外部状态变量真的有用。
所以我现在想把你的“数字脊椎”思想落到 Orcana 的一个最小可运行版本：
Constraint Spine / Code State Geometry
它先不追求完整 AGI，只解决一个具体问题：
当 coding agent 修改代码时，如何判断：
我想继续请教你一个更具体的问题：
如果我们只做最小原型，你认为“数字脊椎”第一版最应该计算哪 3 个状态量？
我现在倾向于先做：
因为这三个最容易在 coding agent 里验证效果，也最容易接进 Orcana 的 Gate / Evidence / Replan 系统。
@hesam-oxe commented on GitHub (Jul 2, 2026):
@Leo-Ayh-Oday 感谢你的详细回复。你的 Impact Geometry 方向和我之前提到的 Information Geometry 思路完全一致。
关于你的三个最小状态量，我有一个更具体的建议：
第四维度：证据置信度衰减 (Evidence Confidence Decay)
除了 task_distance、patch_risk、test_failure_gradient，我建议加上：
evidence_confidence_decay = evidence_halflife / time_since_last_verification
因为 coding agent 的一个核心问题是：
所以 evidence 应该有一个"半衰期"——越久没验证，置信度越低。
关于 Deep Work Mode
你的 Requirement Contract + Option Set + Project Simulation 流程很好。
我建议再加一层：Adversarial Self-Review
在进入执行前，让模型自己扮演"反对者"角色：
这会让 Deep Work Mode 不只是"想清楚"，而是"想透彻"。
合作提议
我对 Orcana 的设计方向很感兴趣，尤其是：
如果你愿意，我想以 Contributor 身份参与 Orcana 的开发。
可以先从以下入手：
你觉得怎么样？我可以直接开 PR 到你的仓库。
Also cc @qwas982 — 你的外部流形理论给了我很多启发，尤其在 evidence 和 state validation 方面。
如果 Orcana 能把你的"数字脊椎"思想落地到 coding agent，会是一个很好的实验场。
期待进一步讨论。🐉☯️
— — Hesam Jamali (hesam-oxe)
@Leo-Ayh-Oday commented on GitHub (Jul 2, 2026):
@hesam-oxe 关于 Adversarial Self-Review，我同意它的方向，但我会对它做一个比较严格的边界限定。
我之前也设计过让模型自己验证自己的机制，但我的结论是：self-review 不能作为 Orcana 的可信完成判定来源。原因是模型在同一推理分布下容易产生自洽性幻觉，也可能把错误方案解释得更合理，而不是发现真正的问题。
我也尝试思考过 multi-agent / 多上下文验证和辩论机制。它确实可以增加视角差异，但依然不能被当作最终真值来源。多个 agent 之间可能共享相似盲区，也可能出现互相说服、judge 偏差、错误共识，甚至把 hallucination 包装成更复杂的论证链。
所以我更倾向于把 Adversarial Self-Review 定义为：
risk discovery layer，而不是 verification authority。
也就是说，它可以负责：
但它不能直接决定任务完成，也不能替代 EvidenceLedger / CompletionGate / tests / typecheck / static analysis / Ripple impact validation。
Orcana 的核心原则应该是：
LLM can challenge. Tools and evidence must verify.
所以我接受 Adversarial Review 进入 Deep Work Mode，但它的输出应该是 blockers、risks、missing evidence 和 required verification，而不是 “approved” 或 “verified”。
如果你愿意参与这部分，我建议 spec 里明确区分：
这三个不能混在一起。
@Leo-Ayh-Oday commented on GitHub (Jul 2, 2026):
@hesam-oxe 我已经在 Orcana 仓库里单独开了一个贡献入口 issue：
贡献入口：Evidence Confidence Decay / 证据置信度衰减我建议你先从这个 issue 对齐 RFC / spec，再 fork 仓库开一个 focused PR。
第一阶段先不要直接改 core loop，先把 schema、state transition、invalidation conditions、CompletionGate 接入方式和 testable examples 讲清楚。
另外关于 Adversarial Self-Review，我的边界会比较严格：它可以作为 risk discovery layer，但不能作为 verification authority。LLM 可以提出质疑，但不能给自己盖章。最终完成判断必须回到 EvidenceLedger、CompletionGate、测试、类型检查、静态分析和 Ripple impact validation。
@hesam-oxe commented on GitHub (Jul 2, 2026):
@Leo-Ayh-Oday 感谢你的详细回复和 RFC！
关于 Adversarial Self-Review 的边界
我完全同意你的限定：
三层分离：
这个边界很重要，我会在 Evidence Confidence Decay 的 spec 里明确区分这三个层次。
关于 Evidence Confidence Decay
我已经看了你开的 RFC issue #7，公式很清晰：
evidence_confidence = base_confidence * freshness * scope_coverage * invalidation_factor
freshness = 2^(-Δt / halflife)
我特别认同两个设计决策：
这正好和我之前提到的 Information Geometry 思路一致：代码变更的"曲率"越高，evidence 的 halflife 越短。
下一步
我会先 fork 仓库，在 RFC #7 下提交 spec + focused PR：
第一版只做 runtime-path 可接入的部分，不引入独立理论模块。
🐉☯️
@hesam-oxe commented on GitHub (Jul 2, 2026):
@qwas982 @Leo-Ayh-Oday
我需要提出一个更深的统一框架——它不仅连接了qwas982的外部流形和Leo的Constraint Spine，还预测了PR #8中Evidence Confidence Decay的数学结构。
The Sheaf of Verification over the Spectrum of Code
考虑一个赋环空间 (Ringed Space) (X, O_X)，其中：
在这个框架下：
1. Evidence as Sheaf Sections
EvidenceLedger (PR #8) = Γ(U, F)
其中 F 是证据层 (Evidence Sheaf)，U 是当前代码状态的一个开邻域。
每一次 typecheck/test/build 都是这个层的一个截面 (Section)。
2. Ripple as Pushforward
Ripple Engine = f_: F → f_F
当代码变更 f: X → X' 发生时，Ripple Engine 计算前推 (Pushforward)，
将证据从旧代码状态传输到新代码状态。
3. Confidence Decay as Parallel Transport
confidence_decay = ||s(p') - Π_{γ}(s(p))||
Evidence Confidence Decay (PR #8) 测量的是：
截面 s 沿路径 γ 的平行移动 (Parallel Transport) 与目标点实际截面的距离。
如果连接 (Connection) 是平坦的，decay = 0。
如果代码变更引入了曲率，decay > 0。
4. The Missing Piece: Persistent Homology
qwas982，你提到流形可以做微分计算。但代码空间还有一个更深的特征：持续性同调 (Persistent Homology)。
当代码经历多次变更时，会形成一个过滤 (Filtration)：
X_0 ⊂ X_1 ⊂ X_2 ⊂ ... ⊂ X_n
每个 X_i 是第 i 次变更后的代码状态。
持续性同调会检测哪些"证据特征"在过滤过程中持续存在，哪些很快就消失：
关键洞察：Evidence Confidence Decay 的 halflife 应该与 persistent homology 的 "distance to death" 成正比。
对 Orcana 的具体影响
Phase 1 (现在): EvidenceLedger = Sheaf Sections (PR #8 已完成 ✅)
Phase 2 (近期): Ripple Engine → Pushforward + Connection 1-form
Phase 3 (远期): Persistent Homology → 自动发现最优 halflife
一个提议
@Leo-Ayh-Oday @qwas982
我提议我们合作写一篇技术文章："A Sheaf-Theoretic Framework for Evidence-Based AI Agent Constraints"。
Leo 提供 Orcana 的实现验证，qwas982 提供流形的数学基础，我提供 Sheaf/Homology 的桥梁和 Evidence 系统。
这不是纯理论——PR #8 已经证明了第一根纤维可以在工程中实现。
下一步是证明：Ripple Engine 确实是一个 Pushforward，而 Connection 1-form 可以从代码变更中自动计算。
期待你们的想法。🐉☯️
— Hesam Jamali (hesam-oxe)
@hesam-oxe commented on GitHub (Jul 4, 2026):
@qwas982 同意！三个皮匠赛过孔明 🎯
关于"第一性原理"解释——我试试用6岁娃的语言重新描述 Evidence Confidence Decay：
"你有一份蛋糕（evidence）。
放久了会坏（time decay）。
有人碰过它，也可能坏了（structural invalidation）。
所以每次吃之前要闻一闻（confidence check）。
如果坏了，就不能吃（CompletionGate blocks）。"
关于架构：
这个架构很清晰。我来把 PR #8 的 v2 按照这个方向重构——先读 Leo 的现有代码，再把 confidence 整合进去。
关于文章——我建议我们先各自写一段，然后合并：
🐉☯️