展示 HN:面向代理系统的、基于 Git 的、带模式的结构化状态

2作者: advancingu6 天前
我研究了如何以 a) 结构化的方式存储代理状态,b) 在没有专用 MCP 内存/状态服务器的情况下运行,并且我能够获得 c) 一条清晰的、可差异化的审计日志,记录所有随时间变化的状态。我没有找到任何符合要求的方法。 在 [https://github.com/commitspark/demo-agentic-mcp](https://github.com/commitspark/demo-agentic-mcp) 中,我演示了一个实现,该实现通过将 Claude 代理与我之前发布的 Commitspark 库及其完全由 Git 支持的 GraphQL API 相结合,满足了这些要求。 在此演示中,模拟了两个独立的 Claude 代理,它们共同完成一个任务跟踪器。第三个代理会审查任何任务更改,并回滚明显不正确的更改。完整的演示记录包含在 README 文件中,包括代理的原始工具调用。 任务代理通过一个小型 MCP 服务器访问数据,该服务器公开了两个 Commitspark API(GraphQL API、Schema API)。然后,这些代理可以获取 schema 并自行编写 GraphQL 调用,GraphQL 会自动强制执行写入的数据符合 schema。验证器代理还可以访问基本的 Git 功能,以查看 diff 和撤销提交。 我正在寻求关于以下方面的反馈:共享代理状态的 schema 验证是否是人们实际遇到的问题,或者在实践中,松散类型的 JSON + 重试是否足够。
查看原文
I looked into how to store agentic state in a) a structured way that b) runs without any dedicated MCP memory&#x2F;state servers and where I can get c) a clear diff-able audit trail of all state changes over time. Nothing that I could find fit the bill.<p>In <a href="https:&#x2F;&#x2F;github.com&#x2F;commitspark&#x2F;demo-agentic-mcp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;commitspark&#x2F;demo-agentic-mcp</a> , I demo an implementation that fulfills these requirements by combining Claude agents with my previously published Commitspark library and its entirely Git-backed GraphQL API.<p>In the demo, two independent Claude agents are simulated that contribute to a task tracker. A third agent reviews any task changes and rolls back obviously bad ones. A full demo transcript is included in the README, including the agents&#x27; raw tool calls.<p>Task agent access to data happens via a small MCP server that exposes two Commitspark APIs (GraphQL API, schema API). These agents can then fetch the schema and author their own GraphQL calls, with GraphQL automatically enforcing written data is schema-conformant. The validator agent additionally has access to basic git functionality to view diffs and revert commits.<p>I&#x27;m looking for feedback specifically on: whether schema validation on shared agent state is a problem people actually have, or whether loosely-typed JSON + retries is good enough in practice.