Skip to content

Releases: Wike-CHI/aer

Release list

AER v0.6.1

AER v0.6.1 Latest
Latest

Choose a tag to compare

View all tags
@Wike-CHI Wike-CHI released this 18 Sep 08:19
v0.6.1
081e8ba

这是一个修复版本

v0.6.0 在 Windows 上装不上：

$ pip install aer-runtime
ERROR: Could not find a version that satisfies the requirement neug==0.2.0
       (from aer-runtime) (from versions: none)
ERROR: No matching distribution found for neug==0.2.0

neug==0.2.0 在 PyPI 上只有 macOS(arm64) 与 Linux(manylinux) 的 wheel——没有 Windows wheel，也没有 sdist。而它被声明成必需依赖，于是整条安装失败，且失败在依赖解析阶段，在 AER 自己的代码被碰到之前。

这不是 v0.6.0 的制品有问题：同一份 wheel 从 PyPI 装进隔离目录后，import aer、AER() 建库、迁移到 0004、写入 Run 全部正常。

改了什么

neug 从必需依赖改为 knowledge extra。这不是权宜之计：整个 aer/ 包里 neug 只有一处引用，而且是函数内导入（aer/knowledge/neug.py），没有任何顶层 import neug。实测把 neug 完全去掉，import aer、AER()、验证、提炼、备份冒烟全部正常，只有引擎侧检索不可用。

pip install aer-runtime                 # 现在在任何平台都能装上
pip install "aer-runtime[knowledge]"    # 再加上检索（NeuG 知识索引）

没有用环境标记（platform_system != 'Windows'）：它把「这个平台没有分发」写成「这个平台不需要」，下一个读到的人会以为引擎在 Windows 上没必要装，而事实是装不上。

生产镜像同步改了：Dockerfile 现在写 --editable '.[knowledge]'。这一步不能漏——否则镜像能构建、能迁移、能过冒烟，然后在生产第一次检索时报 ImportError。CI 现在对着 /app/requirements.frozen.txt 断言 neug 确实在里面。

验证

1033 passed / 2 skipped（本机无 neug wheel，属既有平台跳过）
ruff / format / mypy clean
python -m build + twine check --strict PASSED
元数据  Requires-Dist 只剩 alembic / pydantic / sqlalchemy
        Provides-Extra: knowledge → neug==0.2.0; extra == "knowledge"
制品冒烟  import aer · head_revision()=0004 · AER() 建库并写入 Run
CI      质量门禁 + 容器构建与端到端（含"镜像里真的有 neug"）全绿
生产部署  6/6 冒烟通过 · aer 0.6.1 · revision 0004 (head 0004)

新增一条行为测试：在子进程里用 sys.meta_path 拦截器屏蔽 neug，再 import aer——必须成功。这比语法检查强：CI 上装了引擎，只有主动屏蔽才能证明它「不被需要」。

Windows 依赖解析（修复的直接证明）：

不带 extra     → Would install ... aer-runtime-0.6.1 ...   成功
带 [knowledge] → 明确报 No matching distribution found for neug
                拿不到引擎时在安装期就报错，而不是装完才坏

Highlights（自 v0.6.0 起未变）

Agent 执行轨迹

  • AER 嵌入式运行时 + RunContext 生命周期句柄，无需任何外部服务
  • run.tool() / run.recovery()：异常路径也保证写出结束事件
  • 统一 Error 管道 run.error()：结构化落库 + 脱敏后的 stack trace

独立验证

  • 四类验证器：DETERMINISTIC / ENVIRONMENT / HUMAN / LLM，唯一验证管道
  • verified_success 区分「Agent 说完成」与「独立确认完成」
  • 验证可以发生在 Agent 结束之后，甚至由另一个进程按 run_id 补做

经验提炼

  • kind ∈ {SUCCESS, RECOVERY, FAILURE}，由运行事实判定，Provider 只能建议
  • 失败同样被提炼；FAILURE 不承载 solution
  • 生命周期受状态机约束；REUSED 及以上在用量统计落地前不可达

检索（M6）

  • SQLite → 嵌入式图索引的可重建投影，BM25 + 图过滤
  • 结果分 guidance 与 warnings：只有被独立确认的结果能进 guidance
  • 需要 [knowledge] extra（见上）

工程基础设施

  • SQLite WAL + Alembic 迁移（0001–0004）；已发布 revision 不允许改写
  • 在线备份 / 显式恢复 / 灾难恢复与跨版本恢复演练（均已真实执行）
  • 非 root 容器镜像、CI、CD、备份 → 迁移 → 冒烟 → 记录的部署顺序
  • PyPI Trusted Publishing（OIDC），仓库里没有任何凭据

Core semantics

Agent execution:   SUCCESS     # Agent 做完了它认为该做的事
Verification:      FAILED      # 真实环境没有满足最终要求
Verified success:  FALSE
  • execution success ≠ verified success；verified_success 是派生判断，不落库
  • 执行事实不会被验证结果覆盖；验证失败不改写 Run.status
  • 失败与恢复同样是可复用的经验，但 FAILURE 不承载 solution
  • 未验证的方案不会升级为可信经验（模型 frozen，只能经 transition_to()）
  • 崩溃 ≠ 结论：验证器/提炼器抛异常时写 ERROR，绝不伪造 passed=false

Known limitations

  • 检索需要 [knowledge] extra，且 neug 无 Windows 分发——Windows 上装不了引擎侧检索
    （其余功能全部可用）。
  • 检索只有 BM25 + 图过滤：没有 embedding，没有 HNSW 向量检索。
  • 没有经验使用统计：不记录 reuse_count / success_rate，因此 REUSED 及以上不可达。
  • Sanitizer 尚未完整实现：只覆盖降级 fallback 的 repr 与 stack trace 文本；
    调用方传入的结构化 payload（tool input/output、event payload、verification message）
    是原样落库的    ，不会自动清洗。
  • 没有通用 CLI、没有 FastAPI、没有 Dashboard：唯一的命令行入口是知识索引运维
    （python -m aer.knowledge）。
  • 没有 Workflow / Dataset / 模型训练。
  • 备份只在每次部署前产生 → RPO = 距最近一次成功部署的时间，没有周期性备份。
  • 单机 / 单进程设计：不支持多进程并发写。

安装

pip install aer-runtime                 # 任何平台
pip install "aer-runtime[knowledge]"    # 再加检索（macOS / Linux）

容器：

docker build -t aer:local .
docker run --rm aer:local          # 打印版本后立即退出

文档

许可证：Apache-2.0（LICENSE）

Assets 2
Loading

AER v0.6.0

AER v0.6.0

Choose a tag to compare

View all tags
@Wike-CHI Wike-CHI released this 18 Sep 07:04
v0.6.0
2d4999e

Highlights

Agent 执行轨迹

  • AER 嵌入式运行时 + RunContext 生命周期句柄，无需任何外部服务
  • run.tool() / run.recovery() 上下文管理器：异常路径也保证写出结束事件
  • 统一 Error 管道 run.error()：结构化落库 + 脱敏后的 stack trace
  • Event sequence 严格递增，TASK_START / TASK_END 自动写入

独立验证

  • VerificationEngine 是唯一验证管道，四类验证器：DETERMINISTIC（HttpStatusVerifier /
    H1CountVerifier / JsonValidVerifier / PredicateVerifier）、ENVIRONMENT、HUMAN、LLM
  • verified_success 明确区分「Agent 说完成」与「独立确认完成」
  • 验证可以发生在 Agent 结束之后，甚至可以由另一个进程按 run_id 补做

经验提炼

  • run.distill() → Experience + ExperienceSource，kind ∈ {SUCCESS, RECOVERY, FAILURE}
  • kind 与 status 由确定性代码按运行事实判定，模型只能提供被记录的建议
  • 生命周期受状态机约束（aer/runtime/lifecycle.py 是唯一规则来源）
  • 提炼幂等：同一 Run 重复 distill() 返回同一条；不同 Run 的相同 claim 合并来源

检索（M6）

  • 把 SQLite 里的 Experience 投影到嵌入式图索引（NeuG 0.2.0），用 BM25 + 图过滤做第一版可信检索
  • SQLite 是唯一事实源，NeuG 只是可重建投影：删掉整个 /srv/aer/knowledge，代价是重建一次，不是丢数据
  • 结果分 guidance 与 warnings：只有被独立确认的结果能进 guidance；kind=FAILURE 只进 warnings
  • 运维入口：python -m aer.knowledge status | project | rebuild

工程基础设施

  • SQLite 持久化 + Alembic 迁移（revision 0001–0004）
  • 在线备份（完整性校验 + sidecar 元数据）/ 显式恢复 / 灾难恢复演练
  • Docker 镜像（非 root uid 10001）、CI、CD、不可变镜像
  • 本版本新增：Apache-2.0 LICENSE、CONTRIBUTING.md、SECURITY.md、
    PyPI Trusted Publishing 发布流水线

Core semantics

三条分开的事实，不合并：

Agent execution:   SUCCESS     # Agent 做完了它认为该做的事
Verification:      FAILED      # 真实环境没有满足最终要求
Verified success:  FALSE
  • execution success ≠ verified success. run.success() 只是 Agent 的自述。
  • 验证证据独立于 Agent 自述。 verified_success 是派生判断，不落库。
  • 执行事实不会被验证结果覆盖。 验证失败不改写 Run.status；Tool 失败也不会自动把
    Run 标成 FAILED——Agent 可能自己恢复。
  • 失败与恢复同样是可复用的经验。 verified_success == false 不是丢弃理由；
    Agent 误判成功是最有价值的信号之一。但 FAILURE 不承载 solution。
  • 未验证的方案不会升级为可信经验。 生命周期 RAW → DISTILLED → VERIFIED → … 只能经
    transition_to() / mark_verified() 变更（模型为 frozen）。
  • 崩溃 ≠ 结论。 验证器 / 提炼器抛异常时写 ERROR + ErrorRecord，绝不伪造
    passed=false，也不产出半条 Experience。

Infrastructure

  • SQLite：WAL、外键、synchronous=NORMAL、busy_timeout=5000；八张表
    （runs / events / errors / recoveries / verifications / experiences /
    experience_sources + alembic_version）
  • 迁移：Schema 全程由 Alembic 管理，Base.metadata 只是 autogenerate 的输入；
    已发布的 revision 不允许改写，历史库可前向升到 head
  • 备份 / 恢复：scripts/backup_sqlite.py（在线备份 API + 完整性校验）/
    scripts/restore_sqlite.py（必须显式给源与目标）
  • 灾备已实测，不是承诺：备份在隔离目录被真实恢复、迁移，并由线上镜像冒烟通过（6/6）；
    恢复也可以直接从只读挂载的备份进行。跨版本恢复同样验证过：一份 revision 0003
    的备份经当前镜像恢复到 0004，历史记录逐字段保全
  • 迁移：Schema 变更必须新增 revision；本版新增 D-064——迁移脚本随 wheel 分发，
    使 pip install aer-runtime 成为一条自足的路径
  • 部署：pull → 备份 → 迁移 → 冒烟 → 记录 current.env；任一步失败即失败；
    回滚只切镜像，不自动降级数据库
  • 镜像：非 root（uid 10001）、数据永远在 bind mount、构建期固化 NeuG 全文扩展，
    使检索不需要网络；只用 sha-<commit> 标签，不发可变标签
  • CI/CD：PR 跑质量门禁 + 全新库迁移 + 镜像构建 + 容器端到端；main 重跑门禁后部署
  • 发布：.github/workflows/publish.yml 用 PyPI Trusted Publishing（OIDC），
    仓库中没有任何 PyPI 凭据；上传前会在干净虚拟环境里安装 wheel 并真的建一个库

Known limitations

这一版没有做的事情，写清楚比宣称能力重要：

  • 检索只有 BM25 + 图过滤。 没有 embedding，没有 HNSW 向量检索（留给 M6.5）。
  • 没有经验使用统计。 不记录 reuse_count / success_rate，因此经验生命周期的
    REUSED 及以上不可达——不存在任何到达它们的转换。
  • Sanitizer 尚未完整实现。 现在只覆盖两处：降级 fallback 的 repr 与 stack trace 文本。
    调用方传入的结构化 payload（tool input/output、event payload、verification message）
    是原样落库的，不会被清洗。     不要依赖 AER 替你过滤凭据或个人信息。
  • 没有通用 CLI、没有 FastAPI、没有 Dashboard。 唯一的命令行入口是知识索引运维
    （python -m aer.knowledge），而且它假定 Python 环境里能 import aer。
  • 没有 Workflow、没有 Dataset、没有模型训练。
  • 备份只在每次部署前产生。 所以 RPO = 距最近一次成功部署的时间，没有周期性备份。
  • 单机 / 单进程设计。 不依赖 Redis / Kafka / PostgreSQL / 独立向量库；代价是没有多进程
    并发写的支持（Sequence 分配是单进程锁 + 唯一约束兜底）。
  • PyPI 首次上传需要人工完成一次配置：在 PyPI 登记 Trusted Publisher
    （仓库 Wike-CHI/aer / workflow publish.yml / environment pypi）。
    步骤见 docs/DEPLOYMENT.md 第 20 节。在那之前 pip install aer-runtime 还不成立。

安装

源码（当前推荐）：

git clone https://github.com/Wike-CHI/aer.git
cd aer
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"

容器：

docker build -t aer:local .
docker run --rm aer:local          # 打印版本后立即退出

发行版 pip install aer-runtime 的通道已经建好，但只在首次成功发布到 PyPI 之后成立。

文档

许可证：Apache-2.0（LICENSE）

Loading