依赖创生问题：当 AI 护理智能体改变能动性平衡时的问责

AI护理智能体的部署理由几乎无一例外地诉诸于"独立性"。目标是让护理对象在家中生活更长时间，赋予其更多自主权，减少对人类照护者的依赖——尤其是在通过支持仍可自行处理的任务方面。智能体是对能力的补充，而非替代。

这一框架在部署之初是准确的。但它不会永远保持准确。

一个持续处理某项功能的AI护理智能体——追踪用药时间、监测行动模式、标记营养缺口、管理社交日程——随着时间推移，将减少护理对象主动实践该功能的频率。这并非设计缺陷，而是持续可靠的协助所带来的必然结果。

为何功能性依赖是结构性结果，而非副作用

使AI护理智能体有效的同一机制，也创造了依赖：它们吸收了对重要任务的可靠管理，使使用者不再需要直接管理这些任务。对于本就能力受限的护理对象而言，这种吸收很少被作为风险加以监控，而是被视为既定目标本身。

所创生的依赖是功能性的。护理对象可能在认知和身体层面仍具备智能体所处理功能的能力，但他们停止了实践，停止了对自身判断的信任，并可能失去了使其能够独立恢复该功能的信息基础设施——追踪习惯、维系中的联系人、已建立的日常程序。如果智能体被移除或大幅修改，护理对象无法回到原来的状态，而是回到某种程度上比注册时更为脆弱的处境。

这与自动化萎缩问题不同，后者关注的是监督负责人失去检查智能体工作能力的问题。这里关注的是护理对象自身的功能自主性——该系统名义上服务于其人的实践能力的侵蚀。

硬件基础设施问题

嵌入式AI护理设备创造了这一动态的特定版本。当设备成为家庭护理环境中持久存在的环境层——感知、警报、管理——它开始像供暖和自来水一样作为基础设施运作。设备故障不再是服务中断，而是对日常程序已围绕设备存在而构建起来的当事人而言，是一次福祉事件。

这种转变的问责结构在部署时几乎从未建立起来。护理智能体作为可选工具被治理。只要护理对象在原则上可以在没有设备的情况下生活，它就被视为补充品。而设备已变得不可或缺的那个时刻——当护理对象在实践中无法安全运作时——通常没有被标记、没有被正式记录，也没有反映在任何同意记录或护理计划中。这是逐渐发生的，而治理框架无法识别"逐渐"。

变化时刻的问责缺口

依赖创生问题在变化时刻最为明显：设备停产、软件平台关闭、基础模型被弃用，或固件更新大幅改变了智能体的行为配置。

在那一刻，问责问题纷至沓来。谁负责管理已在功能上依赖该智能体的护理对象的过渡？护理系统中谁知晓这种依赖？谁能从部署记录中重建智能体一直在做什么，以及护理对象需要什么才能通过其他方式替代这些功能？

如果答案是"无人被指定"、"依赖从未被记录"，以及"记录无法支持这种重建"，那么护理系统就已创造了一种重大脆弱性——且没有任何结构性机制来治理它。智能体作为补充被引入；它成了基础设施；问责从未更新以反映这一转变。

正确的架构需要什么

治理依赖轨迹，需要将其视为部署中被追踪的维度，而非落在系统定义范围之外的偶然结果。

这意味着定期评估智能体已吸收哪些功能，以及护理对象不再主动实践哪些功能——并将该评估作为护理记录条目对待，而非非正式的观察。这意味着构建将依赖审计作为长期部署结构性要求（而非可选良好实践）的护理过渡协议。这意味着确保停用或修改事件在设计上触发对护理对象应对变化所需支持的评估。

这还要求对几乎每个护理AI部署所宣称的内容保持理智上的诚实：智能体支持独立性。只有当部署被积极监控着这样的风险——即支持随时间推移已创造了一种未被规划、未被治理、直到系统发生某些变化才会显现的依赖形式——时，"支持独立性"才是一个有意义的主张。

在Asaptic Labs，我们认为正确的框架不是"智能体在部署时是否支持独立性"，而是"护理关系（包括其依赖轨迹）是否在部署生命周期的每个节点都受到治理"。这一问题需要不同的工具化、不同的问责分配，以及对长期AI护理部署对其服务对象实际产生的影响有更为诚实的阐述。