Cindy 是一个开源的桌面和移动客户端，用于编码代理和计算机任务。本指南将客户端与后端分离，解释设置选项并评估该项目。我们将文档化的功能与支持账户、服务或开发相关的功能区分开来。Cindy 将连续性作为核心概念，贯穿不断变化的工具之中。其初始支持的代理包括 Claude Code 和 Codex，同时原生代理正在开发中。

根据自述文件（README），模型和代理可以在保持工作区、记忆、技能和工具连续性的前提下进行切换。请确认对您所选运行时的支持情况。自述文件描述了一种工作流程，可以规划任务、并行执行工作，并在不同的代理和模型组合下审查结果。但这只是产品描述，并非保证每个任务都支持所有组合。

应将 Cindy 视为一个共享工作台，其功能取决于所选的运行时环境。工作区、记忆、技能和工具旨在在您更换模型或代理时保持有用性。在实践中，请检查每个代理可以访问的内容及其指令的解释方式。共享文件夹并不意味着所有运行时都等效，保存的指令可能需要针对不同的工具进行调整。

该项目描述了浏览器和计算机控制功能，以及手机相关的工作流程。请查阅平台文档以了解实际操作中手机支持的含义。Cindy 的目标超越代码编辑器或终端包装器，它将代理工作与应用程序和设备连接起来。可用行为取决于代理支持、权限、配置和服务访问情况。

根据项目描述，工作也可以通过即时消息或计划任务开始。这使得系统既适用于交互式会话，也适用于稍后开始的委托工作。消息或计划触发器不一定是本地的。某些工作流程依赖于服务器支持的服务。在设计自动化之前，请检查接收请求的是哪项服务。

共享的工作区、记忆和技能是 Cindy 连续性故事的一部分。它们可以在您更换模型或代理时，为可重用上下文中的持续工作提供家园。但它们并不能确保每个代理都具有相同的行为，也不能保证所有上下文都适合每项任务。请保持笔记更新并限制对相关上下文的访问。

自述文件描述了重复的计划自动化和 MCP（模型上下文协议）集成，并提到可以从“I am”启动工作。这些是独立的功能，而非一个组合触发器。MCP 依赖于兼容的服务器和配置，而自动化需要其文档化的设置。在依赖特定触发器之前，请检查当前文档和权限。

插件可以通过技能中心安装或手动安装，而共享的开放市场仍在建设中。如果工作流程依赖于某个插件，请先在项目文档中验证其状态。对开发中的功能也应保持同样的谨慎态度。区分路线图方向与已发布的支持功能是必要的。

请将客户端与其服务分开看待。该仓库是 Cindy 客户端，后端是一个独立的项目。桌面应用程序可以使用您自己的计算机进行本地工作，但服务器支持的功能需要服务支持。克隆此仓库不会克隆或启动后端，请勿假设会如此操作。本地代理在您的机器上运行。

Cindy 的托管服务是独立的，在未登录模式下服务器支持的功能不可用。提供商可能会根据其条款单独处理请求。使用前请映射工作流程，确定执行发生的位置、所需的服务以及每个依赖项处理的数据类型。

自述文件列出了 Cindy 托管访问、Claude Code 或 Codex 编码计划授权、个人 API 密钥和本地模型作为使用模型的独立方式。它们并非单一必需的账户安排。请根据现有访问权限和所需功能进行选择。提供商的可用性、授权步骤、成本和限制各不相同。

跳过登录仅支持本地代理。明确地说，不登录就无法使用服务器支持的函数功能。因此，它适合本地使用，而不是匿名解锁托管服务的方法。如果您需要依赖 Cindy 后端的功能，请选择支持的登录路径。请牢记这一区别。

对于仓库设置，文档化的先决条件是 Node 22、pnpm 10 和 Git LFS。兼容的 pnpm 范围是至少 10.7 且低于 11，仓库固定版本为 10.33.2。请使用固定的发布版。匹配声明的工具链可以减少依赖差异，使设置更具可重现性。

首先使用 Cindy 客户端仓库 URL 进行 Git clone，然后进入克隆的项目目录。请使用项目发布的地址，而不是复制未经验证的镜像。接下来，从仓库运行 Git LFS pull。LFS 会检索大型跟踪资产，常规检出可能会遗漏这些文件。

在源代码和大型文件资产就位后，在仓库根目录运行 pnpm install 以安装 monorepo 依赖。顺序是 Node 和 pnpm、Git clone、Git LFS pull，然后是 pnpm install。如果设置失败，请在重复之前检查版本、Git LFS 和网络访问情况。

依赖安装完成后，使用仓库文档中为客户端和目标平台记录的脚本。请阅读 package 脚本而不是猜测开发命令，因为名称和要求可能会改变。桌面开发工作流可能启动本地客户端代码，但仍依赖远程服务以实现某些功能。

对于远程桌面开发，中国大陆账户请选择中国账户区域，其他用户选择全球区域。此工作流程依赖于 Cindy 云账户及其现有的登录状态，它不会启动本地后端。在开始之前，请遵循仓库关于先决条件、配置和设置细节的指导。

Linux 安装途径包括 Ubuntu deb 包、Arch 或 arm64 安装包，以及其他 glibc Linux 桌面的用户安装程序。这并不意味着所有发行版或功能都受支持。请遵循为您系统记录的途径，验证软件包来源，并区分安装发布版与从源代码构建客户端。

根据是否需要托管功能或本地代理来选择账户途径。托管登录启用服务器支持的功能，跳过登录仅支持本地代理。该项目还列出了编码计划授权、个人 API 密钥和本地模型。这些选项之间的提供商要求和授权步骤各不相同。

初始代理是 Claude Code 和 Codex，项目将编码计划授权描述为一种访问选项。请遵循提供商的授权说明，针对您打算使用的代理和账户进行操作。

连接提供商账户并不意味着 Cindy 托管该模型。请遵守提供商的条款和限制，使用您自己的 API 密钥时，账户及其使用情况由您自行管理。仅通过应用程序的安全配置输入凭据，切勿将其写入源代码、共享内存或提交记录中。检查配置的提供商端点及发送的数据，API 密钥路由与托管访问不同。自述文件列出了本地模型作为使用 Cindy 的选项，请检查计划使用的设置所支持运行时和模型要求。不要假设每个模型或功能都能在本地运行，浏览器控制、调度和服务器支持的功能可能依赖于单独的服务。在依赖纯本地配置前，请确认文档范围。

Cindy 声称可以混合或切换不同的框架和模型，同时工作区、记忆、技能和工具保持连续。这有助于比较方法或将任务分配给代理，但这并不抹去质量、成本、条款、能力或访问限制方面的差异。选择适合任务的模型，一种实用的共享工作模式是规划有限任务，并行委托或执行部分操作，并在接受结果前进行审查。延续上下文可以减少阶段间的重复解释，但仍需检查文件更改和输出，特别是当代理使用不同框架时。明确定义任务边界并保持人工主导的审查流程。

共享记忆和技能有助于重复性工作，但需保留假设。移除过时的指令，分离项目指导，切勿在可复用的笔记中保存秘密信息。切换代理前，检查下一个运行时能访问什么以及是否需要相同的上下文。当共享上下文准确且相关时，连续性会有所帮助。该项目描述从即时消息和日程安排开始工作，以及交互式会话。对于调度工作流程，需定义触发条件、运行身份、可访问的工作区及结果审查方式。对于消息传递，请检查集成权限和响应目的地，此类触发器可能依赖于配置的服务。

浏览器和计算机控制将代理扩展到应用程序工作流中，启用操作前需了解权限及后果。从低风险任务开始，观察每一步骤，并对关键更改要求确认。行为取决于框架、操作系统和配置，信任特定工作流前请验证其具体流程。Cindy 被描述为支持桌面和移动设备，涉及手机的工作提供了另一个访问点，但项目并未确立每个桌面功能在所有设备上存在。请确认平台支持和账户要求，将移动访问视为补充，并检查任务执行位置。

MCP 是连接代理客户端与兼容服务器暴露工具的集成区域，每个服务器都可能引入自己的权限、数据访问和风险。仅添加您理解的集成，查阅其文档并先用非敏感任务测试。提及 MCP 并不意味着每个服务器都是安全的。插件仍在开发中，不要依赖假设的市场行为，请检查仓库文档以获取当前可用性。成熟度在客户端、后端、框架和集成间各不相同，需区分计划方向与已发布功能，并在依赖前确认您的具体工作流。

评估每个能力时询问其运行位置及依赖项，本地代理可能无需登录即可工作，而服务器功能在该模式下不可用。托管登录、自动化触发器和外部提供商可能引入单独的数据流，原生框架正在开发中，开放插件市场仍在建设中。官方构建包含与账户关联的设备、操作系统和应用版本分析数据（登录后），心跳报告包括账户、平台和版本信息。项目称分析数据排除聊天内容、文件和工作目录数据，请查阅隐私文档以了解范围及相关服务或提供商的数据流。

崩溃转储被描述为保留在设备上且不会自动上传，这是关于崩溃报告的声明，而非绝对保证没有任何信息离开您的计算机。托管功能、模型提供商和集成可能具有单独的数据流和条款，对于敏感工作请检查相关提供商的条款。有用的隐私审查应追踪每个组件的信息：本地文件、客户端遥测数据、Cindy 服务、框架、模型提供商和任何 MCP 服务器。确定每个组件接收什么及适用的保留规则，切勿在提示或共享笔记中放置凭据。

项目指出分析限制很有帮助，Cindy 客户端仓库使用 Apache License 2.0。该许可允许在条款下参与开源，但这并非对第三方依赖、托管服务条款或模型权重的全面保证。请审查仓库许可证及签出时的通知，并独立评估外部组件。贡献者应使用 Node 22、兼容的 PNPM 10 范围及固定的 10.33.2 版本。克隆客户端，检索 Git LFS 对象并使用 PNPM install 安装，然后遵循文档中的桌面工作流及区域选择（如需远程服务）。后端是独立的，更改代码前需确定行为属于客户端、单独的服务、框架还是集成。

阅读问题和贡献指南，搜索现有报告并保持提议的更改范围集中。在支持的平台上测试更改，清晰的范围有助于维护者正确路由报告。打开拉取请求时解释问题、总结实现并包含实际运行的检查项，遵循仓库的开发者原产地证书指南并按要求签署提交。若未执行请勿声称测试通过，需包含平台、框架和账户上下文。客户端更改可能影响依赖项、打包资产及平台行为，请尊重用于跟踪大文件的 Git LFS。

避免提交生成的秘密或特定于机器的配置，引入新步骤前检查项目脚本。考虑提议的功能是否更需要后端更改而非客户端更改，保持仓库边界清晰。从使架构可见的可逆任务开始评估，仅在拥有必要访问权限时比较本地代理路由与登录后的路由。Cindy 描述切换……

测试所选运行时环境下的行为表现，然后单独评估设备或自动化功能。对于每次测试，记录下哪些部分在本地运行、哪些联系了服务以及哪个提供商或集成处理了请求。确认任务是否无需登录即可工作，并在服务器访问不可用时观察哪些功能会消失。

这种比较将客户端行为与后端行为区分开来，也有助于避免将被验证的行为描述为事实。追踪通过工作区、记忆和技能共享的信息。连续性可以简化重复性工作，但过时的假设可能会误导其他代理或比预期更广泛地暴露上下文。保持可重用指令的更新，避免在通用笔记中放入秘密，并理解本地文件、托管服务和第三方提供商之间的界限。

Cindy 并不使所有代理可互换，其主张是客户端可以让您在保持工作连续性的同时更换运行框架和模型。访问权限、成熟度、提供商行为和服务可用性仍然决定了可能性，因此需直接测试这种权衡。客户端提供灵活性，但底层的访问和成熟度仍有差异。

首先选择一种接入方式，确认文档中的先决条件，并按照您平台的安装说明进行操作。决定托管功能是否必要或本地代理是否足够，然后验证一个真实的工作流，包括其工具、上下文和隐私边界。检查官方客户端仓库以了解功能状态和要求，记住这些区别：这是客户端而非后端；跳过登录支持本地代理而非服务器能力。

初始运行框架包括 Claude Code 和 Codex，原生运行框架正在开发中。Cindy 表示模型和运行框架可以切换，而工作区、记忆、技能和工具保持连续。运行时支持可能有所不同。从一个适度且非敏感的任务开始，确认活动的模型和运行框架，然后检查文件或操作。

如果您需要消息传递、日程安排、浏览器或计算机控制、电话支持、自动化或多协议客户端（MCP），请单独验证每个需求。在扩展工作流之前，基于观察到的行为建立信心而非假设。如果您想改进 Cindy，请检查客户端代码和项目指南。

保持更改聚焦并精确报告您测试的内容。遵循 Apache 2.0 许可证通知、第三方条款以及项目的 DCO（开发者原产地证书）拉取请求流程。清晰的问题或范围谨慎的贡献会有所帮助。

如果本视频阐明了 Cindy 的客户端、本地与后端的界限以及设置选择，请点赞并评论一个要测试的工作流，订阅以获取更多开源开发者教程。在开始之前，请检查官方仓库的安装步骤、功能状态、隐私指南和贡献者说明。