Show HN：Decispher – 为编码代理提供持久化的工程上下文和记忆
5 分•作者: iamalizaidi•27 天前
你好 HN，
我是 Ali，正在开发 Decispher。
我们正在解决的问题是，编码代理会反复重新发现工程组织中已有的上下文。
开发人员在处理一个功能时，可以整合来自先前 PR、Jira 工单、Slack 讨论、所有权边界、架构决策以及他们自身经验的信息。而编码代理通常从一个提示和一个代码库开始，然后花费 token 来搜索相同的上下文，或者完全错过它。
Decispher 是一个面向工程代理的上下文和内存层。
它目前包含三个部分：
1. **上下文引擎 (Context Engine)**
工程上下文通常分散在各个系统中。Decispher 连接来自工程平台的记录，并将相关的片段组合成代理可以为任务检索的上下文单元。
例如，关于一个组件的上下文可能包括先前的 PR、相关问题、架构决策、所有权信息以及实现历史。
我们还构建了 Branch Story，它可以记录 AI 编码会话，并将其执行过程转化为 PR 上的结构化交接：
提示 → 计划 → 操作 → 结果。
2. **内存平面 (Memory Plane)**
内存平面在用户、团队和项目级别存储持久化上下文。
这包括工作偏好和工程约定。团队还可以创建可重用的内存集，例如前端、支付后端或特定项目集，并根据任务注入相关的内存。
在 LongMemEval 上，我们当前的系统达到了：
a) 使用 GPT-4.1-mini 作为提取器和读取器，在 oracle split 上达到 89% 的准确率。
b) 在 LongMemEval -S 数据集上达到 81%（使用前沿模型达到 89%）。
c) 中位数 token 减少 38 倍。
我很乐意分享更多关于我们如何衡量检索质量和 token 减少的细节。
3. **工作代理 (Worker Agent)**
Decispher 还拥有一个自主工作代理，在处理任务时会使用上下文引擎和内存平面。
它可以从 Jira 和 Slack 等来源获取工作，检索相关的上下文和所有权信息，并在可用上下文不足时向相关人员提问，而不是进行猜测。这些答案随后可以作为未来工作的上下文。
上下文引擎、内存平面和工作代理可以独立使用。
**设置**
`npx decispher init`
这会连接一个代码库并配置代理集成。
`npx decispher link`
这会将您的 decispher 账户链接到您的代码库。
Decispher 可与 MCP 兼容的代理配合使用，并提供对 Claude、Codex、Grok Build 和 Cursor 的特定集成。我们还有一个用于查看上下文和编写交接的 VS Code/OpenVSX 扩展。
**注意事项：**
a) 上下文引擎不克隆源代码；它通过 GitHub API 进行读写。
b) 工作代理使用一个隔离的沙箱，除了通过允许列表代理外，没有网络路由。
c) 工作沙箱在运行后会被销毁。
d) 原始消息和文本在静态时加密，并自动清除。会话目前在合并后 7 天或最后活动后 30 天被清除，具有可配置的保留期。
我们还有一个名为 Decision Guardian 的 MIT 许可的开源项目，用于在 PR 上显示 ADR 上下文。
上下文引擎现已可用。内存和工作代理正在逐步推出。
我特别希望获得反馈，并且我们也在寻找设计合作伙伴。
乐意解答。
Ali
这是我之前 Show HN 帖子的后续：
https://news.ycombinator.com/item?id=48762112
自那时以来，主要的新增功能包括内存平面、LongMemEval 结果、工作代理沙箱以及用于 PR 上 AI 生成工作的 Branch Story。
查看原文
Hello HN,<p>I'm Ali, building Decispher.<p>The problem we're working on is that coding agents repeatedly rediscover context that already exists inside an engineering organization.<p>A developer working on a feature can combine information from previous PRs, Jira tickets, Slack discussions, ownership boundaries, architectural decisions and their own experience. Coding agents usually start with a prompt and a repository, then spend tokens searching for that same context—or miss it entirely.<p>Decispher is a context and memory layer for engineering agents.<p>It currently has three parts:<p>1) Context Engine<p>Engineering context is usually fragmented across systems. Decispher connects records from engineering platforms and combines related fragments into context units that agents can retrieve for a task.<p>For example, context around a component might include previous PRs, related issues, architectural decisions, ownership information and implementation history.<p>We also built Branch Story, which records an AI coding session and turns its execution into a structured handoff on the PR:<p>Prompt → plan → actions → result.<p>2) Memory Plane<p>The Memory Plane stores persistent context at the user, team and project levels.<p>This includes working preferences and engineering conventions. Teams can also create reusable memory sets for example frontend, payments-backend, or project-specific sets and inject the relevant memory based on the task.<p>On LongMemEval, our current system reaches:<p>a) 89% accuracy on the oracle split using GPT-4.1-mini as extractor and reader
b) 81% on LongMemEval -S dataset (89% with frontier models)
c) 38× median token reduction<p>I'm happy to share more details about how we measure retrieval quality and token reduction.<p>3) Worker Agent<p>Decispher also has an autonomous worker agent that uses the Context Engine and Memory Plane while working on a task.<p>It can take work from sources such as Jira and Slack, retrieve relevant context and ownership information, and ask the humans involved when the available context is insufficient instead of guessing. Those answers can then become available as context for future work.<p>The Context Engine, Memory Plane and Worker Agent can be used independently.<p>Setup<p>npx decispher init<p>This connects a repository and configures the agent integration.<p>npx decispher link<p>This links your decispher account to your repo.<p>Decispher works with MCP compatible agents, with specific integrations for Claude, Codex, Grok Build and Cursor. We also have a VS Code/OpenVSX extension for viewing context and writing handoffs.<p>Notes:<p>a) The Context Engine does not clone source code; it reads and writes through the GitHub API.
b) The Worker Agent uses an isolated sandbox with no network route out except through an allowlisted proxy.
c) Worker sandboxes are destroyed after a run.
d) Raw messages and text are encrypted at rest and automatically purged. Sessions are currently purged 7 days after merge or 30 days after last activity, with configurable retention.<p>We also have an MIT-licensed open-source project called Decision Guardian for surfacing ADR context on PRs.<p>The Context Engine is available now. Memory and the Worker Agent are rolling out gradually.<p>I'm especially interested in feedback and we are also looking for design partners.<p>Happy to answer.<p>Ali<p>This is a follow-up to my previous Show HN post:<p><a href="https://news.ycombinator.com/item?id=48762112">https://news.ycombinator.com/item?id=48762112</a><p>The major additions since then are the Memory Plane, LongMemEval results, Worker Agent sandboxing and Branch Story for AI-generated work on PRs.