我是一名研究工程师，正在研究和构建面向自主 AI 系统的可信基础设施。
我关心的不只是“智能体能不能完成任务”，还包括几个更基本的问题：它做了什么、在什么条件下做的、留下了哪些证据、别人能不能独立检查，以及一次修改是否真的值得采用。
我正在围绕一个问题展开研究：
一个自主 AI 系统，怎样才能拥有清晰的身份，持续留下可验证的证据，保留有用的经验，并在边界明确的前提下逐步演化？
DCELL 目前仍处于研究方向（RESEARCH_DIRECTION）阶段，不是已经完成的平台。完整的自主适应、跨代经验继承，以及多个系统协作后的能力增长，目前都还没有得到充分验证。
这是一个有明确边界的公开示例，用来观察一次智能体执行，并生成可以查��和复核的执行证据。
- 目前进展： 最小公开路径已有实验支持（
EXPERIMENTALLY_SUPPORTED）；更完整的路径仍是原型（PROTOTYPE）。 - 已有证据： 在 2026 年 8 月 8 日的审计中，最小路径成功运行；当时对应版本的公开构建和验证检查也可以查看。
- 还不能说明： 完整版和企业版路径依赖私有扩展，无法只凭公开仓库独立复现。
SAEE 是一套实验性基础设施，用来评估智能体的健康状态，并比较候选修改到底带来了改善，还是引入了新的问题。
- 目前进展： 已有实验支持（
EXPERIMENTALLY_SUPPORTED）。 - 已有证据： 审计版本通过了 84 项本地单元测试、一次基础整合测试和一个有边界的公开演示。
- 还不能说明： 当时的公开版本没有提供用于运行源代码测试的 CI；这些结果不代表系统已经能够自主改进，也不代表已经可以投入生产。
这个项目研究怎样根据证据约束智能体的行动，并明确记录负面证据和授权边界。
- 目前进展： 已测试的契约层已经实现（
IMPLEMENTED）；更广泛的运行时治理仍只有实验支持（EXPERIMENTALLY_SUPPORTED）。 - 已有证据： 审计版本中的公开契约检查已经通过。
- 还不能说明： 契约检查通过，不等于已经拥有完整的自主运行时，也不代表系统具备独立决策权。
这里仅列状态清楚、可以通过 DOI 公开核验的成果。
A Minimal UDI-DICOM Mapping Profile and Validation Artifact for Medical-Device Imaging Workflows
- 期刊： Journal of Imaging Informatics in Medicine
- 状态： 已在线发表（
ONLINE_PUBLISHED）。 - 在线发表日期： 2026 年 5 月 27 日。
- DOI：
10.1007/s10278-026-02019-6 - 公开阅读： Springer Nature SharedIt 只读全文
- 研究内容： 提出一个最小 UDI-DICOM 映射框架和可复现验证材料，用于检查医疗设备身份与影像元数据之间的证据关系。
- 边界： 研究使用的是有边界的合成场景和验证材料，不代表临床验证、监管批准或医院部署。
A Bounded Public DICOM Metadata Audit for UDI-DICOM Evidence Readiness in Medical Imaging Workflows
- 期刊： Journal of Imaging Informatics in Medicine
- 状态： 已在线发表（
ONLINE_PUBLISHED）。 - DOI：
10.1007/s10278-026-02164-y - 在线发表日期： 2026 年 7 月 29 日。
- 研究内容： 对有限范围的公开 DICOM 元数据进行证据就绪度审计，并使用正向对照和可复现材料解释观察结果。
- 边界： 样本结果不能代表所有公开 DICOM 数据，也不构成临床验证、监管批准或真实医院部署证据。
相关公开参考实现：UDI-DICOM Evidence Validator。它是研究方向的验证工具，不是医疗诊断、临床安全或监管认证系统。
下面只列已经由外部仓库确认合并的代表性 PR。PR 被合并，说明这项具体贡献进入了对方仓库；不等于对方正式采用了我的全部项目或研究框架。
- #1319：增加外部操作责任证据映射说明 把 AGT 运行证据与外部责任证据档案之间的关系说明清楚；已于 2026 年 4 月 22 日合并。
- #1370：增加 AuditEntry 责任证据导出示例
基于真实
AuditService / AuditEntry输出给出最小、稳定的外部导出示例； 已于 2026 年 4 月 24 日合并。
- #76：补充无效委托签名的一致性测试
增加
ACTION-008必须级测试，确保无效签名先被判定为来源证据无效； 已于 2026 年 8 月 3 日合并。
三项外部集成文档已于 2026 年 8 月 5 日至 6 日合并，让相关工具可以从 LangChain 官方文档中被发现和使用。
为了避免把“做出来了”“跑过一次”和“已经成熟”混在一起，我会明确区分下面几种状态。
titmas-agent-action-gate中已经过测试的契约层。- Persona Object Protocol 中经过测试、带版本的身份与人格对象能力。
这里的“已实现”，只指代码、测试或 CI 能直接支持的那一小块技术能力，不代表整个系统已经完成。
verifiable-agent-demo的最小公开执行证据路径。SAEE的智能体健康评估和候选修改评估路径。- 围绕 Action Gate 契约开展的证据治理实验。
这表示有限范围的实验支持了有限范围的结论，不等于已经适用于所有场景，也不等于可以直接投入生产。
- TITMAS Demo：DCELL 研究方向的早期工程起点，也是第一个实验实例，用确定性的方式探索可观察、可验证、可评估健康状态的智能体执行。
verifiable-agent-demo更完整的公开与私有整合路径。- TEK：用于压力测试和候选修改评估的早期原型。
TITMAS 不是 DCELL 的中央控制器。它是一项早期工程实验，应该始终可以被观察、替换、演化或绕过。目前的公开 Demo 也没有证明完整的数字细胞生命周期已经建立。
- DCELL： 研究由证据驱动、有明确边界、可以替换并能持续演化的自主系统。
- 经验连续性： 保存经过验证的成功和失败记录，同时保留来源、适用范围、有效期和撤销机制。
- 采用前评估： 先比较基线与候选行为，再决定一项修改能不能进入实际系统。
这些都是正在研究的技术问题，不是已经完成的能力。
- 有证据支持的经验，可以在不同智能体或不同代际之间安全传递，同时避免传播过时或缺乏依据的结论。
- 一个有明确边界的自主组件，可以被替换或绕过，同时不丢失实验脉络、验证记录和回滚能力。
- 多个受约束的系统可以共同形成不断增长的能力，而不依赖某个无法替代的中央控制器。
这些设想还需要更多公开实验、对照基线、失败案例和可复现结果来验证。
- 一次实验是谁执行的？当时���了什么模型、工具、环境和配置？
- 执行过程中发生了什么？另一个系统能不能独立复核？
- 依赖或环境变化以后，结果还能不能重现？
- 和锁定的基线相比，一项候选修改到底有没有让系统变得更好？
- 失败实验能不能变成适用范围明确、可撤销、可复用的经验？
- 怎样让证据、验证、评估、授权和行动彼此衔接，同时又不混为一谈？
我目前最扎实的公开证据集中在智能体、基础设施和评估。运行环境的记录仍不完整：我还没有展示完整、可移植的环境封装，也没有完成跨环境一致性测试套件。
我更看重这些原则：
- 让来源和版本可以锁定，让结果可以复现；
- 同时保留正向测试和失败测试；
- 按内容生成唯一标识来保存证据，用版本管理身份；
- 不隐藏失败，也不隐藏已知限制；
- 修改进入系统之前，先做评估；
- 缺少证据或权限时，默认停止，而不是自行放行；
- 把技术验证和行动授权分开处理。
观察不等于证据
证据不等于验证
验证不等于评估
评估不等于授权
授权不等于决定
决定不等于执行
规范不等于实现
一次测试通过、一次 CI 成功、一个版本发布、一个 DOI 或一个 Demo 跑通，只能支持它直接检查的对象和范围。它们本身不能证明科学结论已经成立、系统已经生产就绪、外部已经采用，或者系统已经获得行动许可。
我会使用 AI 编码智能体协助实现和复核，但研究问题、实验设计、验收标准、架构决策、证据解释、失败分析和授权决定，仍由人来负责。
我会尽量用可复现材料、失败案例、决策记录和明确的限制说明，让这些责任可以被外部检查。
项目成熟度最近一次审计快照：2026 年 8 月 8 日；论文和外部 PR 状态最近一次核验：2026 年 8 月 15 日。仓库版本、依赖、CI 或可见范围发生变化后，以上结论都需要重新核对。