Chimera 0.74.1：服务停止真的停了，依赖也锁紧了

chimera service stop 命令存在一个竞态条件，导致它“谎报军情”。你让一个后台服务停止，它确认了请求，然后就在进程还在跑着的时候从服务列表里消失了。如果你接着用 chimera service stop --now 去强制干掉卡死的进程，CLI 会告诉你“服务未运行”——即使那个进程还活着，并且占着资源。0.74.1 版本消除了这个空档。

为什么正在停止的服务会“隐身”

一个 Chimera 后台服务运行着一个长生命周期的 agent 循环。当它收到停止信号时，需要完成正在执行的轮次、刷写状态并断开连接。旧代码在服务接受停止请求的那一刻，就把它从追踪器里删掉了。这是一种记账上的偷懒：服务自己知道正在“停止中”，但对系统的其他部分来说，它已经不存在了。

最直接的问题就出在 --now 上。强制停止会去追踪器里查找匹配的服务 ID。如果记录没了，命令就会报告没有可停止的对象并直接退出。而实际进程还在继续跑，占着锁、socket 或 GPU 显存，直到它最终自己清理完或被外部杀死。对于正在排查 agent 卡死问题的运维来说，这意味着工具告诉你一切正常，而进程列表却显示着相反的情况。

这次修复对服务生命周期的改变

现在，从接受停止请求到真正退出，服务会一直以 stopping 状态保留在追踪器里。追踪器持有这条记录，所以后续任何 stop 或 status 调用都能看到它。服务执行优雅关闭——完成当前轮次、持久化需要保存的内容、关闭循环——然后自行移除。只有当进程退出后，这条记录才会消失。

--now 标志仍然存在，但行为更严谨了。它只有在确认追踪到的进程与文件记录中的服务 ID 匹配后，才会发送强制终止信号。如果服务在上一次检查和 --now 调用之间已经干净利落地退出了，命令会如实报告，而不是向一个已被回收的 PID 发送信号。这避免了误杀恰好复用了相同标识符的不相关进程。

对于在一台机器上运行多个 Chimera 服务的人来说，这消除了一类“海森堡 bug”：以前，重启脚本可能会在旧实例还在关闭时就启动新实例，因为脚本看不到旧实例，也就没法等待它。

随此版本发布的依赖补丁

两个间接依赖被升级以关闭安全公告。Chimera agent 代码都不会直接调用它们，但两者都存在于常见工作流的供应链中。

GitPython 升级到 3.2.1。直到 3.2.0 的版本，都只在克隆进子模块后才检查其 .git 路径，这允许精心构造的仓库在克隆操作期间触发路径遍历。如果你的 agent 在工具调用循环中克隆仓库——例如，一个检查 pull request 的代码审查 agent——这个问题就很重要。该公告评级为高严重性。

OpenTelemetry 升级到 1.45.1。之前的版本上限 1.45.0，在解析 tracestate 头时没有限制条目数量。如果有下游服务将无界的 tracestate 反射回你已埋点的 agent，可能导致内存过度消耗。Chimera 自身的追踪接口不受影响，但任何通过 HTTP 向 OpenTelemetry 收集器导出 span 的 agent，都会通过 SDK 暴露于此风险。该公告评级为中严重性。

这两个补丁都是依赖树中的最低版本升级。API 接口没有变化。如果你用 lockfile 锁定了依赖，更新 Chimera 后重新运行依赖解析器就会拉取新版本。

升级

直接安装此版本：

pip install chimera-agent==0.74.1

如果你使用 Chimera CLI 管理运行中的服务，请重启所有长生命周期的 agent，让它们应用修正后的生命周期追踪。包含完整变更日志的发布说明位于 Chimera Agent v0.74.1。