AI 实验：第三方 Agentic 应用的结构 | Karan Kurani
本文介绍了作者在搭建实验性应用 CareLoop 过程中探索的一种新应用形态——“第三方 Agentic 应用”（TPAA）。这类应用不依赖独立封装的前沿模型，而是运行在现有代理框架（如 Claude Code、Codex）之内，由技能、脚本、数据库和执行环境共同定义行为。文章阐述了 TPAA 的构成要素、运行机制以及它如何通过自愈能力降低维护成本。
从 CareLoop 说起
本文是搭建实验性应用 CareLoop 的技术配套文章。关于 CareLoop 是什么、为什么构建它，可以在这里查看。
对于 CareLoop，我交付的不是一个带具体功能的应用，而是预期的输出形态、或者说我所需要的行为，其余工作全部交给代理框架（agent harness）完成。我把这种形态称为“第三方 Agentic 应用”（Third-Party Agentic App，TPAA）。它既不是把前沿模型包装成独立应用的产品，也不是由 AI 提供商开发的，但它完全依赖 AI 提供商及其随附的代理框架——比如 Codex、Claude Code 等。
和 ChatGPT 这类应用一样，CareLoop 的主要界面也是聊天框，但输入和输出可以是任何东西，完全按用户需求定制：没有标准工作流，也没有固定的布局或按钮。
设计 CareLoop 这件事，迫使我拓宽并改变了对编程和应用设计实现的思考方式。现在，我更关注的是高层架构：数据形态、预期行为、对不断膨胀的上下文和数据的管理，以及 AI 需要产出的结果。具体编码反而只占工作的一小部分。
什么是 TPAA：一个三层结构的类比
TPAA 的运转需要以下要素：
- 前沿 AI 模型（frontier model）——由用户选择。
- 与该模型最匹配的默认代理框架——例如 Claude Code 配 Claude 效果最好，Codex 配 GPT Sol，Kimi Work 配 Kimi 模型，等等。这也是由用户选择的。
- 第三方 Agentic 应用（TPAA）——一套自包含的技能、脚本、数据库，以及执行代码所需的环境，它在默认代理框架内部运行，离开代理框架就无法工作。
可以拿消费计算设备的三层结构来类比：硬件对应 LLM 模型，操作系统对应代理框架，最上层的经典第三方应用则对应 TPAA。
TPAA 的用户与未来
这里想先强调一点：TPAA 的最终用户不是程序员。就目前而言，这些用户还属于技术爱好者范畴，因为代理框架向普通大众普及这件事才刚刚开始。不过，将来每个人都会找到自己偏好的框架来运行这类应用。
往远了看，我认为这个代理框架最终会演变成一个跑在用户手机上的设备端代理，能力会相当强。我有相当把握，这在不久的将来就能实现。
TPAA 的结构与特点
作为开发者，我只需要描述清楚那条“理想路径”，剩下的事都由代理替用户完成。这条理想路径靠技能（skills）、脚本、执行环境、数据库结构和护栏（guardrails）来定义和支撑。
CareLoop 内置了针对不同数据类型的接入技能，以及如何处理、存储数据的说明和配套脚本。这样一来，AI 就能专注于用户的实际问题，不必操心数据格式之类的细节。它还具备分诊、检索和整合数据的技能，最终给出有用的输出。这几乎就像是在现有框架之上，又套了一层专门面向某个领域的框架。
应用本身不挑框架——它不是为哪一款框架定制的，可以跑在任何 AI 代理框架上，但必须依托某个框架才能运行。裸的大语言模型（LLM）是跑不起来这个应用的。CareLoop 可以加载到 Codex、Claude Code、Pi、OpenCode 等任意框架中。
但输出会因模型和框架而异——应用输出什么结果，取决于它跑在哪个框架、用哪个模型。所以应用开发者必须想清楚：自己的使用场景更适合哪款模型/框架。这也意味着用户最终体验到的质量会参差不齐。
CareLoop 在 Claude Code 和 Codex 中的输出就有明显差别。事实上，截至 2026 年 8 月，CareLoop 的 Fable 在 Claude Code 里有时会直接拒绝工作，因为涉及健康类问题，被归入了它那个“生物”危险类别。🙄
让 TPAA 正常运行的四个要素
要让这类应用正常运行，需要四样东西：完全动态的技能（skills）、脚本、执行环境配置和数据库。少了任何一样，应用的功能都会出问题。这四样都可以由 AI 修改，并且完全按用户定制，但范围只限定在它自己的使用场景内。
CareLoop 有一堆技能，运行时会动态配合，解决用户的医疗需求。它需要一批预置脚本来高效、正确地完成这件事。为此，它会创建一个 venv（虚拟环境）来安全执行，避免影响用户机器上的其他东西。
它还能安全地自愈——自动更新、自动修复，同时确保动态数据库、执行环境和子应用在更新后不出问题。比如操作系统升级导致对应版本的可执行文件失效，CareLoop 也能自愈。它会频繁地根据用户请求或系统环境，修改或调整自己为用户安装的软件包。当某个奇怪的设置阻止它运行时（比如一个和用户环境冲突的配置，只需要改几行代码就能解决），它也能自愈——应用会修改自身去适应该配置。正因为这种“自愈”能力，从开发者角度看，需要维护的兼容性问题大大减少了。
它还会修复损坏的数据库、刷新数据，并在需要时现场写代码，去完成用户要求的任何事。
关键要点
- TPAA 是一种运行在现有代理框架之上的新应用形态，由技能、脚本、执行环境和数据库共同定义行为。
- 开发者只需描述“理想路径”和护栏，具体实现由代理框架动态完成，编码工作大幅减少。
- TPAA 不绑定特定框架，但输出质量会随模型和框架不同而波动，开发者需选择合适组合。
- TPAA 具备自愈能力，能自动修复更新问题、环境冲突和损坏数据，显著降低长期维护成本。
运行时与执行环境
数据库是动态的，并且与其他用户的数据互不兼容——数据库结构最初由开发者提供一个默认模板，但设计上就允许 AI 代理运行框架（也就是承载 AI 智能体的外壳程序，简称 harness）根据用户交互来动态修改。这种设计会刻意偏离初始结构，逐渐塑造成用户真正需要的样子。运行时间越久，每个用户的数据库就越独特，即使与同一应用的其他用户完全互不兼容，也毫无问题。
实际的数据查询和填充，是在运行时通过即时编写代码来完成的。相比经典应用，与数据库操作相关的执行代码非常少。代理还可以自主创建和维护全新的数据表，完全针对特定用户量身定制。
执行环境同样是动态的——就像数据库一样，应用自带初始执行环境，你可以把它想象成一个带有 venv 指令的 requirements.txt 文件。但关键在于，技能（skill）机制允许 AI 代理在需要时即时安装依赖来帮助用户。举个实例：Careloop 最初并不支持读取 MRI 数据，但它在处理用户上传的 MRI 图像时自行安装了 dicom 库，独立完成了解读任务并回答了用户的问题，期间完全不需要我这个开发者介入技术支持。
执行过程发生在用户自己的机器上，并使用默认的 AI 提供商——这意味着代理应用的开发者几乎不需要承担运行成本。应用默认由运行框架进行沙盒隔离，保障安全边界。
这与经典的非代理应用截然相反。经典应用拥有标准的数据形态和共享数据库、标准（但可定制）的界面、稳定的执行环境，以及可预期的用户体验。
当然，和普通应用一样，开发者会根据用户的反馈，把高频出现的用例逐步整合到官方应用里，在后续更新中统一发布。
与插件模式的比较
仔细琢磨（尤其是眯着眼看），你会发现上面的架构和插件的构建方式其实很接近。但 Careloop 与 Ponytail、Caveman 这类 AI 框架插件之间有一个关键区别：Careloop 本身就是主体存在，它拥有一个有状态、并且承载数据状态的执行环境。Careloop 的核心是信息状态，会在用户使用过程中持续自我更新。插件是无状态、依附于宿主环境的；而 TPAA（即第三方代理式应用）不是这样。
我问 ChatGPT 怎么概括这个区别，它的回答是——
更显著的区别在于，TPAA 拥有一个持久的、针对特定用户的领域环境，并通过代理行为来持续演化它。
新的一系列问题
设计 TPAA 更像是在做元编程，而不是常规编程。设计这样的应用需要一套与经典应用完全不同的思维模式——一切都在动态变化，这种动态性必须刻入每一个设计决策中。
在 TPAA 的语境下，目前仍有几个悬而未决的设计难题：
指令安全与边界控制。 整个应用跑在用户机器上，开发者必须更小心翼翼地编写发给 AI 的指令，避免它失控跑偏。如何为这种场景做设计？默认的 harness 又如何保障代码执行和数据安全？
供应链攻击风险。 在这类环境中，供应链攻击会演变成什么形态？尤其 TPAA 被期望在后台动态安装软件以帮用户解决问题，这等于打开了新的攻击面。
恶意软件审查。 提供商和 harness 要如何应对流氓应用或恶意软件？
提供商选择权。 开发者要如何告诉用户，哪个提供商或 harness 最适合自己的应用？开发者该不该控制哪些提供商能使用它的应用？如果要控制，又怎么强制执行？
架构兼容性。 如何设计一种架构，让它能够兼容这么多不断变化的部件？
这些都是 TPAA 从理论走向实用之前必须回答的问题——而目前，还没有现成的标准答案。
关键要点
- 数据库、执行环境、依赖安装在 TPAA 中都保持动态，随用户使用而持续演化。
- 代理应用运行在用户机器上，由 harness 沙盒隔离，开发者无需承担运行成本。
- TPAA 与插件的关键区别在于：它是拥有持久、有状态环境的独立主体，而插件只是依附于宿主环境的无状态扩展。
- 动态环境带来四个核心隐患：指令安全、供应链攻击、恶意软件审查、架构兼容性。