Harmonist结构化记忆原理correlation_id与30类密钥扫描如何让记忆不可伪造【免费下载链接】harmonistPortable AI agent orchestration with mechanical protocol enforcement. 186 agents, zero runtime dependencies.项目地址: https://gitcode.com/gh_mirrors/ha/harmonistHarmonist 是一个可移植的 AI Agent 编排包其中结构化记忆是它的核心机制之一每条记忆都带有由钩子hooks生成的 correlation_id 任务序列号写入前还要通过 30 余类密钥模式扫描与严格的 schema 校验。这套设计让 AI 助手记下的东西既无法被 LLM 伪造身份也不会把密钥泄露进记忆文件。 为什么 AI Agent 的记忆默认不可信让 AI Agent 把项目状态写进一个自由格式的 markdown 文件听起来很简单。但问题在于LLM 可能不诚实——忘记更新、重复记录、甚至编造时间戳密钥容易混入——调试记录里随手一贴AWS_SECRET_ACCESS_KEY就被永久写进了记忆无法追溯——一条架构决策到底属于哪次任务说不清。Harmonist 的答案是 memory/SCHEMA.md 中定义的Memory Schema v1三个固定角色文件 机器可读的条目结构 强制校验一条都不能少。文件类型职责session-handoff.mdstate项目状态的滚动快照最新条目即权威状态decisions.mddecision只增不改的架构决策记录patterns.mdpattern经验教训——什么有效、什么踩坑每条记忆都包裹在!-- memory-entry:start --与!-- memory-entry:end --标记之间内部是一段 YAML 前置元数据frontmatter。文件里允许随意写自由文本但只有结构化块受契约约束校验器只认契约。 correlation_idLLM 无法伪造的任务序列号这是 Harmonist 记忆防伪造的关键设计correlation_id 不是由 LLM 生成的而是由强制执行的 hooks 生成的见 memory/README.md。它的格式是session_id-task_seqsession_id 会话启动那一刻的 Unix 秒级时间戳task_seq从 0 开始只有当 stop 门任务完成闸门判定任务成功结束并放行后才自增 1。当前活跃的 correlation_id 存放在.cursor/hooks/.state/session.json的active_correlation_id字段中。记忆 CLI memory/memory.py 在追加条目时会自动读取它把id、correlation_id、时间戳at全部自动填入。!-- memory-entry:start -- --- id: 1745333456-0-state correlation_id: 1745333456-0 at: 2026-04-22T19:30:56Z kind: state status: done author: orchestrator summary: Integrated Stripe webhook handler for checkout flow --- 正文内容 !-- memory-entry:end --这一机制带来三重防伪效果身份绑定同一次任务中写入的state快照、decision决策、pattern经验共享同一个 correlation_id可以精确追溯这个决策是在哪次任务中做出的时间不可撒谎task_seq只能被 hooks/scripts/gate-stop.sh 在任务通过校验后递增LLM 无法提前给自己签发未来任务的编号写错即拒收校验器 memory/validate.py 会检查条目的correlation_id是否匹配写入时刻的活跃值不匹配直接报错人工手写条目在加--allow-manual时才放行。此外条目的id由correlation_id-kind派生并全局去重——重复的id会被validate.py当作硬性错误报出。换句话说连这条记忆叫什么名字都不由 LLM 说了算。 30类密钥扫描秘密信息永远进不了记忆Harmonist 假设记忆文件迟早会被误提交进某个仓库所以在memory.py append时就拦截一切疑似凭据。打开 memory/memory.py 的_SECRET_PATTERNS可以看到一条精心调校的清单覆盖 30 余类真实密钥形态类别涵盖示例云厂商AWS Access Key / Secret Key、GCP 服务账号、Azure 连接串与 SAS 令牌、Google API Key、DigitalOcean PAT代码托管GitHub PAT / OAuth / 细粒度令牌、GitLab PAT、npm、PyPI、Docker HubAI 服务OpenAIsk-...、Anthropicsk-ant-...协作/消息Slack 令牌与 Webhook、Discord Bot Token、Telegram Bot Token支付/邮件Stripe 密钥、Twilio SID、SendGrid、Mailgun通用兜底JWTeyJ...、PEM 私钥块、24 词助记符、带账号密码的数据库 URL光靠固定模式还不够Harmonist 还叠了两层智能检测上下文 UUID 识别UUID 本身不是密钥但当它出现在heroku或postmark字样前后 ±60 字符范围内时就会被判定为 API 密钥并拦截高熵令牌兜底对 28 字符以上的裸令牌计算香农熵超过 4.3 bit/char 即报警——随机生成的 base64/blob 分数远高于人类可读文本。更妙的是占位符感知被PLACEHOLDER、${VAR}、$(cmd)、{{ template }}这类围栏包住的匹配会被跳过所以文档示例里的假密钥不会误报而真实密钥躲在哪里都会被逮住。命中后 CLI 会拒绝追加并列出命中的类别只有显式加上--allow-secrets才能强行写入。️ 写入即校验回滚、去重与泄漏审计最后一道防线在写入路径上写前验证、失败回滚——渲染好的条目块先过一遍validate.py校验不过就把刚写入的内容整块撤销绝不留半成品去重守卫——新条目的summary与全文任一条目重复、或正文的 blake2s 哈希与已有条目相同换了个说法、内容一字未改都会被拒收防止记忆被反复灌水跨进程文件锁——并发的两个追加不会抢注同一个 id也不会交错回滚事后审计——万一记忆文件真的被误提交agents/scripts/scan_memory_leaks.py 会遍历 git 历史列出当前和历史上所有被追踪的.cursor/memory/文件并直接生成可复制的git rm --cached/git filter-repo清除方案。 动手看看源码想了解的机制去哪里看完整契约字段约束、correlation_id 规则memory/SCHEMA.md记忆 CLI 与三层密钥扫描memory/memory.py逐条 schema 校验与 id 全局唯一性memory/validate.py任务完成后递增 task_seq 的闸门hooks/scripts/gate-stop.sh记忆文件泄漏审计agents/scripts/scan_memory_leaks.py隐私约定.gitignore与.shared.mdmemory/README.md小结Harmonist 的结构化记忆本质上回答了一个问题如何让你不信任的 LLM 写出可信任的记录。用hooks 生成 correlation_id让谁、在哪次任务、何时由机器说了算LLM 只能填写内容用30 余类密钥模式 上下文识别 高熵兜底把秘密挡在记忆之外用写前校验 失败回滚 全文去重 事后泄漏审计把写坏了变成不可能事件。三层机制叠加记忆文件就从AI 随手记的便签升级成了可验证、可追溯、不可伪造的项目档案。【免费下载链接】harmonistPortable AI agent orchestration with mechanical protocol enforcement. 186 agents, zero runtime dependencies.项目地址: https://gitcode.com/gh_mirrors/ha/harmonist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Harmonist结构化记忆原理：correlation_id与30类密钥扫描如何让记忆不可伪造
Harmonist结构化记忆原理correlation_id与30类密钥扫描如何让记忆不可伪造【免费下载链接】harmonistPortable AI agent orchestration with mechanical protocol enforcement. 186 agents, zero runtime dependencies.项目地址: https://gitcode.com/gh_mirrors/ha/harmonistHarmonist 是一个可移植的 AI Agent 编排包其中结构化记忆是它的核心机制之一每条记忆都带有由钩子hooks生成的 correlation_id 任务序列号写入前还要通过 30 余类密钥模式扫描与严格的 schema 校验。这套设计让 AI 助手记下的东西既无法被 LLM 伪造身份也不会把密钥泄露进记忆文件。 为什么 AI Agent 的记忆默认不可信让 AI Agent 把项目状态写进一个自由格式的 markdown 文件听起来很简单。但问题在于LLM 可能不诚实——忘记更新、重复记录、甚至编造时间戳密钥容易混入——调试记录里随手一贴AWS_SECRET_ACCESS_KEY就被永久写进了记忆无法追溯——一条架构决策到底属于哪次任务说不清。Harmonist 的答案是 memory/SCHEMA.md 中定义的Memory Schema v1三个固定角色文件 机器可读的条目结构 强制校验一条都不能少。文件类型职责session-handoff.mdstate项目状态的滚动快照最新条目即权威状态decisions.mddecision只增不改的架构决策记录patterns.mdpattern经验教训——什么有效、什么踩坑每条记忆都包裹在!-- memory-entry:start --与!-- memory-entry:end --标记之间内部是一段 YAML 前置元数据frontmatter。文件里允许随意写自由文本但只有结构化块受契约约束校验器只认契约。 correlation_idLLM 无法伪造的任务序列号这是 Harmonist 记忆防伪造的关键设计correlation_id 不是由 LLM 生成的而是由强制执行的 hooks 生成的见 memory/README.md。它的格式是session_id-task_seqsession_id 会话启动那一刻的 Unix 秒级时间戳task_seq从 0 开始只有当 stop 门任务完成闸门判定任务成功结束并放行后才自增 1。当前活跃的 correlation_id 存放在.cursor/hooks/.state/session.json的active_correlation_id字段中。记忆 CLI memory/memory.py 在追加条目时会自动读取它把id、correlation_id、时间戳at全部自动填入。!-- memory-entry:start -- --- id: 1745333456-0-state correlation_id: 1745333456-0 at: 2026-04-22T19:30:56Z kind: state status: done author: orchestrator summary: Integrated Stripe webhook handler for checkout flow --- 正文内容 !-- memory-entry:end --这一机制带来三重防伪效果身份绑定同一次任务中写入的state快照、decision决策、pattern经验共享同一个 correlation_id可以精确追溯这个决策是在哪次任务中做出的时间不可撒谎task_seq只能被 hooks/scripts/gate-stop.sh 在任务通过校验后递增LLM 无法提前给自己签发未来任务的编号写错即拒收校验器 memory/validate.py 会检查条目的correlation_id是否匹配写入时刻的活跃值不匹配直接报错人工手写条目在加--allow-manual时才放行。此外条目的id由correlation_id-kind派生并全局去重——重复的id会被validate.py当作硬性错误报出。换句话说连这条记忆叫什么名字都不由 LLM 说了算。 30类密钥扫描秘密信息永远进不了记忆Harmonist 假设记忆文件迟早会被误提交进某个仓库所以在memory.py append时就拦截一切疑似凭据。打开 memory/memory.py 的_SECRET_PATTERNS可以看到一条精心调校的清单覆盖 30 余类真实密钥形态类别涵盖示例云厂商AWS Access Key / Secret Key、GCP 服务账号、Azure 连接串与 SAS 令牌、Google API Key、DigitalOcean PAT代码托管GitHub PAT / OAuth / 细粒度令牌、GitLab PAT、npm、PyPI、Docker HubAI 服务OpenAIsk-...、Anthropicsk-ant-...协作/消息Slack 令牌与 Webhook、Discord Bot Token、Telegram Bot Token支付/邮件Stripe 密钥、Twilio SID、SendGrid、Mailgun通用兜底JWTeyJ...、PEM 私钥块、24 词助记符、带账号密码的数据库 URL光靠固定模式还不够Harmonist 还叠了两层智能检测上下文 UUID 识别UUID 本身不是密钥但当它出现在heroku或postmark字样前后 ±60 字符范围内时就会被判定为 API 密钥并拦截高熵令牌兜底对 28 字符以上的裸令牌计算香农熵超过 4.3 bit/char 即报警——随机生成的 base64/blob 分数远高于人类可读文本。更妙的是占位符感知被PLACEHOLDER、${VAR}、$(cmd)、{{ template }}这类围栏包住的匹配会被跳过所以文档示例里的假密钥不会误报而真实密钥躲在哪里都会被逮住。命中后 CLI 会拒绝追加并列出命中的类别只有显式加上--allow-secrets才能强行写入。️ 写入即校验回滚、去重与泄漏审计最后一道防线在写入路径上写前验证、失败回滚——渲染好的条目块先过一遍validate.py校验不过就把刚写入的内容整块撤销绝不留半成品去重守卫——新条目的summary与全文任一条目重复、或正文的 blake2s 哈希与已有条目相同换了个说法、内容一字未改都会被拒收防止记忆被反复灌水跨进程文件锁——并发的两个追加不会抢注同一个 id也不会交错回滚事后审计——万一记忆文件真的被误提交agents/scripts/scan_memory_leaks.py 会遍历 git 历史列出当前和历史上所有被追踪的.cursor/memory/文件并直接生成可复制的git rm --cached/git filter-repo清除方案。 动手看看源码想了解的机制去哪里看完整契约字段约束、correlation_id 规则memory/SCHEMA.md记忆 CLI 与三层密钥扫描memory/memory.py逐条 schema 校验与 id 全局唯一性memory/validate.py任务完成后递增 task_seq 的闸门hooks/scripts/gate-stop.sh记忆文件泄漏审计agents/scripts/scan_memory_leaks.py隐私约定.gitignore与.shared.mdmemory/README.md小结Harmonist 的结构化记忆本质上回答了一个问题如何让你不信任的 LLM 写出可信任的记录。用hooks 生成 correlation_id让谁、在哪次任务、何时由机器说了算LLM 只能填写内容用30 余类密钥模式 上下文识别 高熵兜底把秘密挡在记忆之外用写前校验 失败回滚 全文去重 事后泄漏审计把写坏了变成不可能事件。三层机制叠加记忆文件就从AI 随手记的便签升级成了可验证、可追溯、不可伪造的项目档案。【免费下载链接】harmonistPortable AI agent orchestration with mechanical protocol enforcement. 186 agents, zero runtime dependencies.项目地址: https://gitcode.com/gh_mirrors/ha/harmonist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考