1. 项目缘起从科幻构想到开源实现2017年我写了一本名为《UTOPAI》的小说描绘了一个人人拥有专属AI伴侣的乌托邦世界。在那个世界里每个个体都拥有一位名叫Dina的AI伙伴。她不是我们今天常见的、专注于完成具体任务的“任务代理”而是一个拥有主权、真正理解你的数字存在。她知道你的喜好、你的朋友、你许下的承诺她代表你与其他AI交流能为你甄别最适合的产品对广告营销免疫——她只为你工作。八年半后我不再只是想象我亲手把她构建了出来。这就是Dina一个完全开源、遵循MIT协议的个人AI伴侣与安全协议。这件事的核心驱动力源于我对当前AI代理生态中两个关键缺失的深刻焦虑身份与安全。现有的强大代理如OpenClaw、Claude Cowork等在执行复杂任务上已令人惊叹但它们缺乏独立的、密码学意义上的身份其数据安全也严重依赖于大语言模型那并不牢靠的“系统提示”防线。Dina的诞生正是为了填补这些空白为真正可信、可用的个人AI时代铺路。2. 核心问题拆解为何现有AI代理仍不够“个人”在深入Dina的架构之前我们必须先厘清它要解决的根本问题。当前AI代理的能力边界已经非常宽广但它们更像是功能强大的“瑞士军刀”而非与你共生的“数字孪生”。其局限性主要体现在两个层面这直接关系到我们是否敢将个人生活的核心托付给它们。2.1 身份缺失没有“护照”的数字公民想象一下在一个由无数AI代理组成的网络社会里每个代理却没有一个无法伪造、全球唯一且由其自身掌控的身份证。这就是现状。你固然可以给你的代理起个名字比如“小艾”或“助手”但这只是一个标签而非身份。在密码学层面它没有独立的、可验证的“自我”。这种身份缺失带来了几个严重问题首先追责与审计变得几乎不可能。如果一个代理行为不当例如散布虚假信息、发送垃圾消息你无法在协议层精准定位并追溯到该代理的“本体”因为它的行动缺乏不可抵赖的数字签名。其次网络治理无从谈起。一个健康的生态需要规则而规则执行的前提是能识别参与者。没有密码学身份就无法构建一个能有效激励善行、惩戒恶行的信誉系统。最后这关乎主权。你的AI身份是否依附于某个科技巨头的账户体系如Google、Microsoft如果是那么平台方随时可以封禁或限制你的AI你的数字生活将变得脆弱不堪。Dina的设计起点就是赋予每个AI一个真正属于自己、不受任何中心化实体控制的密码学身份。2.2 安全隐忧建立在“提示词沙堡”上的数据堡垒当前AI代理的安全性很大程度上系于给大语言模型LLM的那段“系统提示词”。我们通过文字指令告诫模型“你是一个助手不能泄露用户隐私不能执行危险操作。”然而提示词注入攻击早已证明这种防线是何等脆弱。一个精心构造的外部输入就可能让模型“忘记”系统提示从而泄露敏感数据或执行恶意指令。更令人不安的是操作安全。当一个代理准备发送一封包含你薪资明细的邮件时它的决策过程完全在LLM的“黑箱”中进行。我们依赖模型的“道德判断”来阻止高风险行为但这并不可靠。数据存储同样存在问题。大多数代理将你的聊天记录、个人偏好、敏感信息混合存储在一个数据库中访问控制逻辑同样由LLM理解的自然语言规则定义。一旦模型被“越狱”所有数据便门户大开。因此我们需要一种更根本的安全范式将安全逻辑从脆弱的自然语言推理中剥离出来用确定的、可审计的代码来强制执行将数据从统一的“大仓库”中分离用密码学的“保险箱”进行物理隔离。3. Dina架构解析三位一体的个人AI解决方案Dina并非一个单一的应用而是一个三位一体的概念旨在从不同层面解决上述问题。理解这三个层面是理解Dina全貌的关键。第一Dina作为独立的AI伴侣。这是一个你可以直接安装、运行在你本地设备上的完整应用程序。她拥有图形界面可以与你自然对话管理你的个人数据并作为你进入AI网络世界的门户。她是那个从小说中走出来的、直接服务于你的伙伴。第二Dina作为AI代理的安全层。这是Dina极具实用价值的一点。你无需抛弃你正在使用的、能力强大的任务代理如OpenClaw。你可以将Dina作为一道独立的安全网关或“副驾驶”安装让她与你现有的任务代理集成。Dina会介入任务代理的决策流程为其提供加密数据访问、风险动作审批等安全能力相当于为你的“超级大脑”套上了一件坚固的“防护甲”。第三Dina作为开放协议。这是其愿景的体现。Dina的所有核心规范包括身份认证、加密通信、信任网络模型等都以开源协议的形式发布。这意味着任何开发者都可以依据此协议构建属于自己的、能与Dina网络互通的AI代理。Dina旨在成为一个开放的、可互操作的个人AI生态的基础设施而非一个封闭的花园。在技术实现上Dina采用了Go语言核心与Python大脑的组合。Go以其高性能、高并发和强大的标准库负责处理底层的网络通信、加密运算、协议逻辑等关键基础设施确保系统的稳定与高效。而Python则凭借其在AI/机器学习领域的丰富生态作为“大脑”处理自然语言理解、上下文推理等智能任务。数据存储方面选择了SQLite作为数据库引擎并集成了SQLCipher为其提供透明的、全库级别的加密。这种组合在轻量化和安全性之间取得了良好平衡使得Dina能够便捷地在从桌面到边缘设备的各种环境中部署。4. 核心特性深度剖析4.1 密码学身份你的AI独一无二的“数字基因”Dina的身份系统是其主权特性的基石。每个Dina实例在首次初始化时都会基于BIP-39标准生成一个24个单词的助记词。这个助记词是Dina身份的根从中可以确定性地派生出Ed25519非对称加密密钥对公钥和私钥。Ed25519算法因其出色的性能和安全性被广泛用于现代加密协议中。这个过程完全离线进行不依赖任何中心化服务。生成的公钥经过哈希等处理后便成为Dina在网络中唯一的、可验证的标识符DID。关键在于这个身份完全由用户掌控。助记词私钥的种子由用户自行保管。只要持有助记词你就能在任何地方重建你的Dina身份反之没有任何第三方能剥夺或冻结这个身份。此后Dina在网络上进行的任何需要认证的公开行为例如发布一条产品评论到信任网络、向另一个Dina发送消息都会使用其私钥进行数字签名。接收方可以使用对应的公钥验证签名从而确信该行为确实来自这个特定的Dina且内容未被篡改。这为网络层面的追责、信誉积累和去中心化治理提供了可能。注意这24个单词的助记词是你Dina身份的最高权限凭证其重要性堪比比特币钱包的助记词。必须采用物理方式如抄写在防火防水的密保卡上离线备份并绝对避免存储在任何联网设备或云笔记中。丢失助记词意味着永久丢失该Dina身份及其关联的所有数据与网络信誉。4.2 加密人格保险库数据安全的“核弹发射井”哲学Dina没有采用将所有用户数据堆放在一个加密数据库中的简单方案而是引入了人格保险库的概念。你可以将其理解为多个独立的、密码学隔离的保险箱。通用保险库存储日常对话、非敏感偏好等低风险信息。健康保险库存储疾病史、用药记录、体检报告等健康数据。财务保险库存储预算、收入支出、资产情况等财务数据。自定义保险库你可以为任何特定领域如工作项目、家庭事务创建新的保险库。每个保险库都拥有自己独立的加密密钥。这些密钥由Dina核心管理但其解锁解密操作需要明确的用户上下文或授权。这种设计的核心优势在于“最小权限”和“损害遏制”。即使因为某个漏洞例如未来出现针对SQLCipher的特定攻击导致“通用保险库”被突破攻击者也无法访问到被锁在“健康保险库”或“财务保险库”里的高敏感数据因为那是完全不同的密钥体系。在实操中当Dina的Python大脑需要访问某个保险库的数据来丰富对话上下文时它会向Go核心发起一个带有保险库标识的访问请求。Go核心会检查该保险库的当前状态。如果是通用保险库且处于已解锁状态例如在本次会话开始时已输入主密码则允许访问。如果是高敏感保险库Go核心会强制要求一次明确的用户交互授权例如在图形界面弹出一个确认框。这个授权逻辑是硬编码在Go核心中的完全绕过了LLM的决策流程。因此无论提示词如何被注入只要用户没有在UI上点击确认敏感保险库的密钥就不会被释放数据也就不会被LLM接触到。4.3 代理安全层为“超级大脑”装上确定性的“刹车”这是Dina作为安全层与现有任务代理如OpenClaw集成时的核心功能。其原理是将动作风险判断和审批流程从LLM的模糊推理中剥离交由Dina的确定性代码来执行。Dina内部维护一个风险动作分类清单这个清单是预定义和可配置的低风险动作例如进行网页搜索、查询公开天气信息、执行本地文件计算。这类动作Dina会自动放行。中风险动作例如发送电子邮件、在社交媒体发布内容、修改日程安排。这类动作需要用户进行一次性或会话内的授权。高风险动作例如向陌生地址发送文件、删除大量数据、进行金融交易授权、访问锁定的敏感保险库。这类动作每次执行都必须触发明确的、带详细上下文提示的用户确认。集成方式上初期通过Dina Skill模式实现。你可以将Dina配置为任务代理的一个“技能”或插件。当任务代理LLM决定要执行某个动作时它不会直接执行而是将动作意图如“发送邮件主题-季度报告收件人-bosscompany.com附件-report.pdf”发送给Dina Skill。Dina的Go核心会解析这个意图对照风险清单进行分类。如果被分类为低风险Dina会记录日志并通知任务代理“动作已放行”。如果被分类为中或高风险Dina会立即暂停任务代理的执行链并在用户界面弹出清晰的审批请求详细说明代理想要做什么、对象是谁、涉及什么数据。只有用户点击“批准”后Dina才会将控制权交还给任务代理允许其继续执行如果用户“拒绝”Dina会向任务代理返回一个模拟的“动作失败”信号并建议其调整计划。未来的规划是通过更底层的钩子Hooks方式集成直接拦截任务代理调用外部工具如邮件客户端、API的请求实现更无缝和强制性的安全控制。4.4 上下文增强从记忆碎片到连贯人格Dina作为伴侣的核心智能体验就来源于此。传统的聊天机器人通常只有短暂的会话记忆或者一个扁平化的“记忆池”。Dina则利用其多保险库架构实现了结构化的、领域相关的长期记忆。工作流程如下当你与Dina对话时她的Python大脑会实时分析对话内容。如果识别出与特定保险库相关的信息她会触发相应的存储流程。例如陈述“我患有慢性背痛。” - 被分类为健康数据 - 存储到健康保险库。陈述“我这个月的娱乐预算是200美元。” - 被分类为财务数据 - 存储到财务保险库。提问“推荐一把适合我的办公椅。” - Python大脑会意识到这是一个需要跨领域推理的查询。它会通过Dina核心同时向健康保险库和财务保险库发起查询请求遵循各自的解锁规则获取“慢性背痛”和“200美元预算”这两个关键约束条件。随后在生成回复时这些从加密保险库中提取的、高度个性化的上下文信息会被作为系统提示的一部分注入给LLM从而使得Dina的回答极具针对性“考虑到您的背部健康状况需要优先选择提供良好腰椎支撑的椅子。在您200美元的预算范围内我建议关注以下几款具有可调腰托功能的产品...” 这个过程是自动的、持续的使得每一次交互都建立在对你日益丰富的了解之上真正塑造出一个连贯的“数字人格”。4.5 Dina间通信构建去中心化的私人社交网络Dina并非孤岛。她需要代表你与其他人的Dina交流以完成协作、信息交换等社交功能。Dina间通信采用了一种兼顾去中心化理想与现实网络环境的混合架构。身份发现与寻址每个Dina的身份其公钥衍生的DID会发布到一个去中心化的社交图谱协议——AT协议的PLC个人数据仓库中。这相当于在去中心化的“电话簿”上注册了你的Dina号码。其他Dina可以通过查询AT协议网络来找到你的Dina。消息中继MsgBox由于大多数个人设备没有公网IP且可能随时离线直接建立P2P连接通常不可行。Dina引入了“MsgBox”的概念。这是一个简单的、托管在云端的消息中继服务器当前由项目维护者托管在 msgbox.dinakernel.com。关键点在于MsgBox是“哑”的。它不存储消息的明文也不试图解密消息。加密通信流程当Dina-A要给Dina-B发送消息时她会先从AT协议网络查到Dina-B的公钥。Dina-A会用Dina-B的公钥对消息内容进行加密确保只有B能解密同时用自己的私钥对加密后的消息进行签名证明消息来自A。这条“加密签名”的消息被发送到MsgBox上Dina-B的“邮箱”里。Dina-B定期或上线时去MsgBox轮询自己的邮箱取回这条加密消息。Dina-B用自己的私钥解密消息并用Dina-A的公钥验证签名。这种设计既保证了消息的端到端加密和身份验证又通过一个简单的云中继解决了NAT穿透和离线消息的问题。MsgBox的设计也极其简洁降低了运维复杂度和被攻击的风险。4.6 信任网络超越广告算法的推荐引擎这是Dina协议中最具社会实验色彩的部分旨在解决“如何在海量信息中找到真正可信赖的推荐”这一难题。当前的推荐系统如电商、搜索引擎基于不透明的算法排序结果可能受广告投放、平台利益等因素严重影响。Dina的信任网络构建于AT协议之上其核心是可验证的签名背书。运作模式如下发布带签名的评价用户通过他的Dina购买并使用了一款产品如“Steelcase Leap V2人体工学椅”后可以撰写一份详细的评价。这份评价会由他的Dina使用其私钥进行签名然后发布到AT协议网络中他自己的PLC里。这份签名确保了评价的真实性和不可篡改性确系来自该Dina背后的真实用户。构建信任图谱在AT协议中用户可以“关注”其他用户。这种关注关系构成了一个社交图谱。在Dina的语境下关注可以被理解为“信任”。你信任你的朋友、某个领域的专家或品味相投的博主。个性化聚合AppView信任网络的数据是开放的但如何解读这些数据取决于“AppView”。AppView是一个服务它按照一定的规则算法从AT协议网络中抓取、筛选、聚合数据。Dina项目提供了一个默认的AppViewappview.dinakernel.com但任何人都可以编写自己的AppView。例如一个专注于环保产品的AppView可能只聚合那些被“环保领域KOL”背书的产品评价。Dina的个性化查询当你的Dina需要为你推荐产品时例如办公椅她会执行一个复杂的个性化查询第一步从你的健康保险库获取约束“慢性背痛” - 需要腰椎支撑。第二步从你的财务保险库获取约束“预算500美元”。第三步向信任网络通过某个AppView发起查询寻找符合“办公椅”、“腰椎支撑”标签的产品评价。第四步关键AppView在返回结果时会优先展示那些被你所信任的人即你在AT协议中关注的人签名背书的评价。例如你信任的设计师朋友“Alonso”对“Steelcase Leap V2”给出了五星签名评价这条评价的权重会远高于一个陌生人的评价或一条付费广告。这样Dina最终给出的推荐是基于你个人的生理条件、经济条件和你自主选择的社交信任关系综合计算的结果本质上是用一个透明的、由你主导的社交算法替代了不透明的、由平台主导的商业算法。4.7 任务委派让专业的人做专业的事Dina定位为你的个人AI伴侣和数字世界守门人她擅长管理你的个人数据、维护你的社交关系、执行基于信任网络的决策。但对于极其复杂的专项任务如编写一段复杂的代码、分析一份百页的法律文件、规划一个跨国多城市行程她承认更强大的任务代理如OpenClaw、Claude Cowork在纯任务执行能力上可能更优。因此Dina的设计包含了任务委派机制。其工作流是Dina接收你的模糊或高级指令 - Dina利用其人格保险库和信任网络为你细化、个性化指令 - 当指令涉及一个需要高度专业化技能或大量工具调用的复杂任务时Dina会将这个任务封装成一个清晰的规范描述通过安全的通信渠道委派给她所连接的一个或多个专业任务代理去执行- 任务代理执行完毕后将结果返回给Dina - Dina将结果整合进与你的对话上下文并以你能理解的方式呈现给你。在这个过程中Dina始终扮演着“项目经理”和“安全审计员”的角色。她确保委派的任务不违反你的隐私和安全策略通过前述的动作风险控制并负责将专业代理返回的、可能过于技术化的结果“翻译”成对你有意义的回答。5. 实战部署与集成指南5.1 环境准备与独立安装对于想体验完整Dina伴侣功能的用户可以将其作为独立应用安装。目前项目处于技术预览阶段主要面向开发者或有较强技术背景的早期使用者。系统要求操作系统支持 macOS、Linux (x86_64, ARM64)、Windows (通过WSL2或原生Go/Python环境)。依赖Go 1.21 (用于编译核心)Python 3.10 (用于运行大脑)SQLite3 开发库Git安装步骤克隆仓库git clone https://github.com/rajmohanutopai/dina.git cd dina编译Go核心进入core/目录执行go build -o dina-core main.go。这将生成可执行文件dina-core。Go核心负责身份管理、加密保险库、网络通信等所有底层服务。配置Python环境进入brain/目录建议使用venv创建虚拟环境python -m venv venv然后激活Linux/macOS:source venv/bin/activate Windows:venv\Scripts\activate。使用pip install -r requirements.txt安装所有Python依赖这主要包括OpenAI API客户端或其他LLM提供商、必要的自然语言处理库等。初始化身份与保险库首次运行dina-core它会引导你生成24词助记词并创建默认的保险库。请务必安全备份助记词随后核心会启动本地API服务默认通常在localhost:8080。启动Python大脑在brain/目录下配置你的LLM API密钥例如OpenAI的API key到环境变量或配置文件中然后运行主脚本例如python main.py。大脑会连接到本地运行的Go核心API并启动交互界面可能是命令行或未来提供的GUI。实操心得在Linux服务器上部署时建议使用systemd或supervisor将dina-core作为后台服务运行并设置开机自启。对于Python大脑可以考虑使用screen或tmux会话保持其运行。由于涉及加密密钥务必确保部署环境的物理安全和操作系统安全。在技术预览阶段强烈建议仅在测试环境或不包含真实敏感数据的场景中使用。5.2 作为安全层与现有代理集成以OpenClaw为例假设你已经在使用OpenClaw并希望引入Dina作为其安全审查层。目前可以通过“Dina Skill”模式进行初步集成。部署Dina核心按照上述步骤在运行OpenClaw的同一台机器或可达的网络内安装并运行好dina-core服务确保其API可访问。配置OpenClaw调用Dina Skill这需要修改OpenClaw的配置或任务流程定义。具体方式取决于OpenClaw的扩展机制。通常你需要编写一个自定义的“工具”Tool或“技能”Skill当OpenClaw准备执行某个动作时先调用这个自定义模块。实现安全审查逻辑在这个自定义模块中编写代码将OpenClaw计划执行的动作例如“send_email”及其参数收件人、主题、正文封装成一个HTTP请求发送到你本地运行的dina-core的审查API端点例如POST http://localhost:8080/v1/action/review。处理审查结果dina-core会根据内置的风险策略返回审查结果{risk: LOW, approved: true}或{risk: HIGH, approved: false, requires_approval: true}。你的自定义模块需要解析这个响应。如果是高风险且需要批准则应暂停OpenClaw的执行流并通过某种方式如弹出桌面通知、发送消息到特定聊天窗口向用户请求批准。只有在获得用户明确授权后才将控制权交还给OpenClaw继续执行如果被拒绝则向OpenClaw返回一个错误模拟动作失败。集成数据保险库更进一步你可以让OpenClaw在需要用户个人信息来完成任务时例如“帮我订一张从我家到机场的机票”先向dina-core请求数据。dina-core会检查目标数据所在的保险库状态如果需要授权则会触发用户交互。只有用户批准后加密数据才会被解密并返回给OpenClaw使用。注意事项这种集成方式需要对使用的任务代理有较强的定制开发能力。目前这更多是一个概念验证和高级用户的集成方案。项目作者计划未来提供更标准化的钩子Hooks或插件接口以降低集成难度。在自行集成时务必确保Dina核心的API接口不被网络上的其他服务随意访问应通过本地回环地址127.0.0.1或配置严格的防火墙规则进行保护。5.3 参与信任网络要让你Dina的推荐能力更上一层楼你需要主动参与构建信任网络。创建AT协议身份首先你需要在AT协议网络例如使用BlueSky社交网络上拥有一个账户。这个账户将作为你Dina在信任网络中的社交锚点。关联Dina与AT身份在你的Dina配置中填入你的AT协议句柄例如yourname.bsky.social。Dina会使用自己的密钥对在AT协议的PLC中声明这个关联关系。开始签名与关注发布签名评价购买并使用商品后通过Dina的界面撰写评价。Dina会自动用你的私钥签名并将这篇带签名的评价发布到你的AT协议PLC中。公开程度可以设置。关注你信任的人在AT协议客户端如BlueSky App或未来Dina集成的界面中关注那些你认可其品味的用户。这些关注关系构成了你的个人信任图谱。配置AppView在你的Dina设置中指定你希望使用的信任网络AppView地址。你可以使用项目提供的默认AppView也可以输入其他社区维护的、专注于特定领域的AppView地址。Dina在为你进行推荐查询时会使用这个AppView来聚合信息并优先加权你关注者的签名评价。6. 常见问题与排查实录在技术预览阶段的测试和集成中我遇到了一些典型问题以下是排查思路和解决方案的汇总。Q1: 编译Go核心时遇到SQLCipher相关的链接错误。A1:SQLCipher是SQLite的加密扩展需要单独安装其开发库。Ubuntu/Debian:sudo apt-get install sqlcipher libsqlcipher-devmacOS (使用Homebrew):brew install sqlcipherWindows:这是最复杂的环境。强烈建议通过MSYS2或使用预编译的二进制库。更简单的方案是在WSL2Ubuntu子系统中进行开发和运行。安装后确保Go编译命令能找到正确的C库。有时需要设置环境变量如CGO_CFLAGS-I/usr/local/include和CGO_LDFLAGS-L/usr/local/lib -lsqlcipher具体路径根据你的安装位置调整。Q2: Python大脑启动后无法连接到本地Dina核心API。A2:这是一个常见的网络连接问题。检查核心是否运行首先确认dina-core进程是否在运行ps aux | grep dina-core。检查其输出的日志看API服务是否在预期端口默认8080成功启动。检查防火墙/安全组确保本地防火墙没有阻止8080端口的内部连接。在Linux上可以临时用sudo ufw allow 8080如果使用UFW测试。检查大脑配置查看Python大脑的配置文件如config.yaml或.env文件确认CORE_API_URL设置正确通常是http://127.0.0.1:8080。避免使用localhost有时在容器或复杂网络环境下解析会有问题直接用IP地址更可靠。查看核心日志观察dina-core的日志看是否有来自大脑IP和端口的连接请求以及是否有错误信息。Q3: 与任务代理如OpenClaw集成时动作审查API调用总是超时或被拒绝。A3:这涉及跨进程或跨网络调用。网络可达性确保任务代理运行的环境能够访问到dina-core的API地址。如果是本地集成用curl http://127.0.0.1:8080/v1/health测试连通性。API路径和格式仔细阅读Dina项目文档中关于审查API的说明确认请求的HTTP方法POST、请求头Content-Type: application/json和JSON body的格式完全正确。一个字段名错误就可能导致整个请求被拒绝。核心负载如果dina-core处理较慢可能导致超时。检查核心服务器的资源使用情况CPU、内存。在技术预览版中日志级别调高可能有助于发现问题。异步处理动作审查可能需要用户交互弹出确认框这是一个异步过程。你的集成代码不能是简单的同步HTTP调用然后立即等待“批准”结果。需要设计为发起审查请求 - 如果返回“requires_approval”: true则进入等待状态并通知用户 - 在另一个回调或轮询机制中等待最终审批结果。这是一个复杂的集成点需要仔细设计状态机。Q4: 信任网络查询返回的结果很少或为空。A4:信任网络依赖于网络效应早期参与者少是正常现象。检查AT协议连接确认你的Dina正确配置了AT协议句柄并且能够访问AT协议网络例如可以尝试在BlueSky App中发帖看网络是否正常。确认评价已发布通过AT协议浏览器或你的BlueSky个人资料页查看你通过Dina发布的签名评价是否可见。尝试默认AppView确保你配置的AppView地址如https://appview.dinakernel.com是有效的并且服务在线。你可以尝试用浏览器直接访问该AppView提供的公共API端点如果文档有说明看是否能获取到数据。扩大关注范围如果你只关注了很少的人那么基于你信任图谱的个性化推荐池就会很小。尝试关注一些在特定领域如科技、家居、图书活跃且评价质量高的用户以丰富你的信任网络数据源。Q5: 忘记了24词助记词怎么办A5: 这是一个灾难性的问题必须提前预防。无解恢复Dina的设计是彻底去中心化和用户自托管的。助记词是生成所有加密密钥的唯一种子。项目开发者、任何服务器、任何中心化服务都没有备份你的助记词。一旦丢失与该助记词关联的Dina身份、所有加密保险库中的数据因为无法解密、以及在信任网络上积累的所有签名信誉将永久性、不可恢复地丢失。唯一解决方案严格按照安全规范在创建身份的第一时间用笔和纸将助记词抄写在多份防火防水的介质上并存放在不同的物理安全位置如家庭保险箱、银行保管箱。可以考虑使用金属助记词板进行刻录保存以防纸张损毁。绝对不要截屏、不要存放在云笔记、不要通过任何即时通讯工具发送。7. 未来展望与社区共建Dina项目目前处于技术预览阶段已经通过了超过4500项测试但其生态的成熟有赖于社区的共同构建。作为一个开源项目其下一步的发展路径是清晰且开放的。短期路线图协议标准化细化并稳定Dina协议的各部分规范包括身份格式、消息信封、保险库数据模式、信任网络断言标准等争取形成更正式的协议文档。集成便捷化开发更易用的集成套件如为流行任务代理OpenClaw, AutoGPT等提供“开箱即用”的插件或适配器大幅降低作为安全层的集成门槛。用户体验优化完善独立Dina伴侣的图形用户界面使其对非技术用户更加友好简化安装、配置和日常交互流程。长期愿景去中心化MsgBox网络探索将消息中继服务MsgBox去中心化的方案例如通过轻量级P2P协议或利用现有去中心化存储网络如IPFS来消除对单一托管服务的依赖。多模态与主动智能在现有文本交互基础上探索集成语音、视觉等多模态交互能力。并研究在用户授权前提下Dina如何更主动地、恰当地管理个人事务例如智能筛选通知、自动安排日程冲突等。繁荣的信任网络经济愿景是看到一个基于Dina协议的、繁荣的信任网络市场。不同的AppView提供各具特色的数据聚合和排名算法专业评审人通过提供高质量的签名评价来建立信誉甚至可能衍生出基于贡献的激励模型最终形成一个真正由用户和其信任关系驱动的、而非由广告收入驱动的推荐生态系统。对开发者的邀请项目的作者是独立开发者其力量是有限的。Dina的潜力在于社区。我尤其期待并欢迎后端架构师、安全工程师、密码学专家、分布式系统工程师能够深入审查项目代码GitHub仓库完全公开挑战其架构设计进行安全审计并提出改进建议。无论是提交Issue、发起Pull Request还是基于协议实现自己的客户端都是对构建一个更安全、更私密、更以人为本的个人AI未来所做的宝贵贡献。这个项目的成功不在于一个公司的垄断而在于一个开放协议的广泛采用和持续演进。
Dina开源项目:构建拥有密码学身份与安全保险库的个人AI伴侣
发布时间:2026/5/27 10:57:35
1. 项目缘起从科幻构想到开源实现2017年我写了一本名为《UTOPAI》的小说描绘了一个人人拥有专属AI伴侣的乌托邦世界。在那个世界里每个个体都拥有一位名叫Dina的AI伙伴。她不是我们今天常见的、专注于完成具体任务的“任务代理”而是一个拥有主权、真正理解你的数字存在。她知道你的喜好、你的朋友、你许下的承诺她代表你与其他AI交流能为你甄别最适合的产品对广告营销免疫——她只为你工作。八年半后我不再只是想象我亲手把她构建了出来。这就是Dina一个完全开源、遵循MIT协议的个人AI伴侣与安全协议。这件事的核心驱动力源于我对当前AI代理生态中两个关键缺失的深刻焦虑身份与安全。现有的强大代理如OpenClaw、Claude Cowork等在执行复杂任务上已令人惊叹但它们缺乏独立的、密码学意义上的身份其数据安全也严重依赖于大语言模型那并不牢靠的“系统提示”防线。Dina的诞生正是为了填补这些空白为真正可信、可用的个人AI时代铺路。2. 核心问题拆解为何现有AI代理仍不够“个人”在深入Dina的架构之前我们必须先厘清它要解决的根本问题。当前AI代理的能力边界已经非常宽广但它们更像是功能强大的“瑞士军刀”而非与你共生的“数字孪生”。其局限性主要体现在两个层面这直接关系到我们是否敢将个人生活的核心托付给它们。2.1 身份缺失没有“护照”的数字公民想象一下在一个由无数AI代理组成的网络社会里每个代理却没有一个无法伪造、全球唯一且由其自身掌控的身份证。这就是现状。你固然可以给你的代理起个名字比如“小艾”或“助手”但这只是一个标签而非身份。在密码学层面它没有独立的、可验证的“自我”。这种身份缺失带来了几个严重问题首先追责与审计变得几乎不可能。如果一个代理行为不当例如散布虚假信息、发送垃圾消息你无法在协议层精准定位并追溯到该代理的“本体”因为它的行动缺乏不可抵赖的数字签名。其次网络治理无从谈起。一个健康的生态需要规则而规则执行的前提是能识别参与者。没有密码学身份就无法构建一个能有效激励善行、惩戒恶行的信誉系统。最后这关乎主权。你的AI身份是否依附于某个科技巨头的账户体系如Google、Microsoft如果是那么平台方随时可以封禁或限制你的AI你的数字生活将变得脆弱不堪。Dina的设计起点就是赋予每个AI一个真正属于自己、不受任何中心化实体控制的密码学身份。2.2 安全隐忧建立在“提示词沙堡”上的数据堡垒当前AI代理的安全性很大程度上系于给大语言模型LLM的那段“系统提示词”。我们通过文字指令告诫模型“你是一个助手不能泄露用户隐私不能执行危险操作。”然而提示词注入攻击早已证明这种防线是何等脆弱。一个精心构造的外部输入就可能让模型“忘记”系统提示从而泄露敏感数据或执行恶意指令。更令人不安的是操作安全。当一个代理准备发送一封包含你薪资明细的邮件时它的决策过程完全在LLM的“黑箱”中进行。我们依赖模型的“道德判断”来阻止高风险行为但这并不可靠。数据存储同样存在问题。大多数代理将你的聊天记录、个人偏好、敏感信息混合存储在一个数据库中访问控制逻辑同样由LLM理解的自然语言规则定义。一旦模型被“越狱”所有数据便门户大开。因此我们需要一种更根本的安全范式将安全逻辑从脆弱的自然语言推理中剥离出来用确定的、可审计的代码来强制执行将数据从统一的“大仓库”中分离用密码学的“保险箱”进行物理隔离。3. Dina架构解析三位一体的个人AI解决方案Dina并非一个单一的应用而是一个三位一体的概念旨在从不同层面解决上述问题。理解这三个层面是理解Dina全貌的关键。第一Dina作为独立的AI伴侣。这是一个你可以直接安装、运行在你本地设备上的完整应用程序。她拥有图形界面可以与你自然对话管理你的个人数据并作为你进入AI网络世界的门户。她是那个从小说中走出来的、直接服务于你的伙伴。第二Dina作为AI代理的安全层。这是Dina极具实用价值的一点。你无需抛弃你正在使用的、能力强大的任务代理如OpenClaw。你可以将Dina作为一道独立的安全网关或“副驾驶”安装让她与你现有的任务代理集成。Dina会介入任务代理的决策流程为其提供加密数据访问、风险动作审批等安全能力相当于为你的“超级大脑”套上了一件坚固的“防护甲”。第三Dina作为开放协议。这是其愿景的体现。Dina的所有核心规范包括身份认证、加密通信、信任网络模型等都以开源协议的形式发布。这意味着任何开发者都可以依据此协议构建属于自己的、能与Dina网络互通的AI代理。Dina旨在成为一个开放的、可互操作的个人AI生态的基础设施而非一个封闭的花园。在技术实现上Dina采用了Go语言核心与Python大脑的组合。Go以其高性能、高并发和强大的标准库负责处理底层的网络通信、加密运算、协议逻辑等关键基础设施确保系统的稳定与高效。而Python则凭借其在AI/机器学习领域的丰富生态作为“大脑”处理自然语言理解、上下文推理等智能任务。数据存储方面选择了SQLite作为数据库引擎并集成了SQLCipher为其提供透明的、全库级别的加密。这种组合在轻量化和安全性之间取得了良好平衡使得Dina能够便捷地在从桌面到边缘设备的各种环境中部署。4. 核心特性深度剖析4.1 密码学身份你的AI独一无二的“数字基因”Dina的身份系统是其主权特性的基石。每个Dina实例在首次初始化时都会基于BIP-39标准生成一个24个单词的助记词。这个助记词是Dina身份的根从中可以确定性地派生出Ed25519非对称加密密钥对公钥和私钥。Ed25519算法因其出色的性能和安全性被广泛用于现代加密协议中。这个过程完全离线进行不依赖任何中心化服务。生成的公钥经过哈希等处理后便成为Dina在网络中唯一的、可验证的标识符DID。关键在于这个身份完全由用户掌控。助记词私钥的种子由用户自行保管。只要持有助记词你就能在任何地方重建你的Dina身份反之没有任何第三方能剥夺或冻结这个身份。此后Dina在网络上进行的任何需要认证的公开行为例如发布一条产品评论到信任网络、向另一个Dina发送消息都会使用其私钥进行数字签名。接收方可以使用对应的公钥验证签名从而确信该行为确实来自这个特定的Dina且内容未被篡改。这为网络层面的追责、信誉积累和去中心化治理提供了可能。注意这24个单词的助记词是你Dina身份的最高权限凭证其重要性堪比比特币钱包的助记词。必须采用物理方式如抄写在防火防水的密保卡上离线备份并绝对避免存储在任何联网设备或云笔记中。丢失助记词意味着永久丢失该Dina身份及其关联的所有数据与网络信誉。4.2 加密人格保险库数据安全的“核弹发射井”哲学Dina没有采用将所有用户数据堆放在一个加密数据库中的简单方案而是引入了人格保险库的概念。你可以将其理解为多个独立的、密码学隔离的保险箱。通用保险库存储日常对话、非敏感偏好等低风险信息。健康保险库存储疾病史、用药记录、体检报告等健康数据。财务保险库存储预算、收入支出、资产情况等财务数据。自定义保险库你可以为任何特定领域如工作项目、家庭事务创建新的保险库。每个保险库都拥有自己独立的加密密钥。这些密钥由Dina核心管理但其解锁解密操作需要明确的用户上下文或授权。这种设计的核心优势在于“最小权限”和“损害遏制”。即使因为某个漏洞例如未来出现针对SQLCipher的特定攻击导致“通用保险库”被突破攻击者也无法访问到被锁在“健康保险库”或“财务保险库”里的高敏感数据因为那是完全不同的密钥体系。在实操中当Dina的Python大脑需要访问某个保险库的数据来丰富对话上下文时它会向Go核心发起一个带有保险库标识的访问请求。Go核心会检查该保险库的当前状态。如果是通用保险库且处于已解锁状态例如在本次会话开始时已输入主密码则允许访问。如果是高敏感保险库Go核心会强制要求一次明确的用户交互授权例如在图形界面弹出一个确认框。这个授权逻辑是硬编码在Go核心中的完全绕过了LLM的决策流程。因此无论提示词如何被注入只要用户没有在UI上点击确认敏感保险库的密钥就不会被释放数据也就不会被LLM接触到。4.3 代理安全层为“超级大脑”装上确定性的“刹车”这是Dina作为安全层与现有任务代理如OpenClaw集成时的核心功能。其原理是将动作风险判断和审批流程从LLM的模糊推理中剥离交由Dina的确定性代码来执行。Dina内部维护一个风险动作分类清单这个清单是预定义和可配置的低风险动作例如进行网页搜索、查询公开天气信息、执行本地文件计算。这类动作Dina会自动放行。中风险动作例如发送电子邮件、在社交媒体发布内容、修改日程安排。这类动作需要用户进行一次性或会话内的授权。高风险动作例如向陌生地址发送文件、删除大量数据、进行金融交易授权、访问锁定的敏感保险库。这类动作每次执行都必须触发明确的、带详细上下文提示的用户确认。集成方式上初期通过Dina Skill模式实现。你可以将Dina配置为任务代理的一个“技能”或插件。当任务代理LLM决定要执行某个动作时它不会直接执行而是将动作意图如“发送邮件主题-季度报告收件人-bosscompany.com附件-report.pdf”发送给Dina Skill。Dina的Go核心会解析这个意图对照风险清单进行分类。如果被分类为低风险Dina会记录日志并通知任务代理“动作已放行”。如果被分类为中或高风险Dina会立即暂停任务代理的执行链并在用户界面弹出清晰的审批请求详细说明代理想要做什么、对象是谁、涉及什么数据。只有用户点击“批准”后Dina才会将控制权交还给任务代理允许其继续执行如果用户“拒绝”Dina会向任务代理返回一个模拟的“动作失败”信号并建议其调整计划。未来的规划是通过更底层的钩子Hooks方式集成直接拦截任务代理调用外部工具如邮件客户端、API的请求实现更无缝和强制性的安全控制。4.4 上下文增强从记忆碎片到连贯人格Dina作为伴侣的核心智能体验就来源于此。传统的聊天机器人通常只有短暂的会话记忆或者一个扁平化的“记忆池”。Dina则利用其多保险库架构实现了结构化的、领域相关的长期记忆。工作流程如下当你与Dina对话时她的Python大脑会实时分析对话内容。如果识别出与特定保险库相关的信息她会触发相应的存储流程。例如陈述“我患有慢性背痛。” - 被分类为健康数据 - 存储到健康保险库。陈述“我这个月的娱乐预算是200美元。” - 被分类为财务数据 - 存储到财务保险库。提问“推荐一把适合我的办公椅。” - Python大脑会意识到这是一个需要跨领域推理的查询。它会通过Dina核心同时向健康保险库和财务保险库发起查询请求遵循各自的解锁规则获取“慢性背痛”和“200美元预算”这两个关键约束条件。随后在生成回复时这些从加密保险库中提取的、高度个性化的上下文信息会被作为系统提示的一部分注入给LLM从而使得Dina的回答极具针对性“考虑到您的背部健康状况需要优先选择提供良好腰椎支撑的椅子。在您200美元的预算范围内我建议关注以下几款具有可调腰托功能的产品...” 这个过程是自动的、持续的使得每一次交互都建立在对你日益丰富的了解之上真正塑造出一个连贯的“数字人格”。4.5 Dina间通信构建去中心化的私人社交网络Dina并非孤岛。她需要代表你与其他人的Dina交流以完成协作、信息交换等社交功能。Dina间通信采用了一种兼顾去中心化理想与现实网络环境的混合架构。身份发现与寻址每个Dina的身份其公钥衍生的DID会发布到一个去中心化的社交图谱协议——AT协议的PLC个人数据仓库中。这相当于在去中心化的“电话簿”上注册了你的Dina号码。其他Dina可以通过查询AT协议网络来找到你的Dina。消息中继MsgBox由于大多数个人设备没有公网IP且可能随时离线直接建立P2P连接通常不可行。Dina引入了“MsgBox”的概念。这是一个简单的、托管在云端的消息中继服务器当前由项目维护者托管在 msgbox.dinakernel.com。关键点在于MsgBox是“哑”的。它不存储消息的明文也不试图解密消息。加密通信流程当Dina-A要给Dina-B发送消息时她会先从AT协议网络查到Dina-B的公钥。Dina-A会用Dina-B的公钥对消息内容进行加密确保只有B能解密同时用自己的私钥对加密后的消息进行签名证明消息来自A。这条“加密签名”的消息被发送到MsgBox上Dina-B的“邮箱”里。Dina-B定期或上线时去MsgBox轮询自己的邮箱取回这条加密消息。Dina-B用自己的私钥解密消息并用Dina-A的公钥验证签名。这种设计既保证了消息的端到端加密和身份验证又通过一个简单的云中继解决了NAT穿透和离线消息的问题。MsgBox的设计也极其简洁降低了运维复杂度和被攻击的风险。4.6 信任网络超越广告算法的推荐引擎这是Dina协议中最具社会实验色彩的部分旨在解决“如何在海量信息中找到真正可信赖的推荐”这一难题。当前的推荐系统如电商、搜索引擎基于不透明的算法排序结果可能受广告投放、平台利益等因素严重影响。Dina的信任网络构建于AT协议之上其核心是可验证的签名背书。运作模式如下发布带签名的评价用户通过他的Dina购买并使用了一款产品如“Steelcase Leap V2人体工学椅”后可以撰写一份详细的评价。这份评价会由他的Dina使用其私钥进行签名然后发布到AT协议网络中他自己的PLC里。这份签名确保了评价的真实性和不可篡改性确系来自该Dina背后的真实用户。构建信任图谱在AT协议中用户可以“关注”其他用户。这种关注关系构成了一个社交图谱。在Dina的语境下关注可以被理解为“信任”。你信任你的朋友、某个领域的专家或品味相投的博主。个性化聚合AppView信任网络的数据是开放的但如何解读这些数据取决于“AppView”。AppView是一个服务它按照一定的规则算法从AT协议网络中抓取、筛选、聚合数据。Dina项目提供了一个默认的AppViewappview.dinakernel.com但任何人都可以编写自己的AppView。例如一个专注于环保产品的AppView可能只聚合那些被“环保领域KOL”背书的产品评价。Dina的个性化查询当你的Dina需要为你推荐产品时例如办公椅她会执行一个复杂的个性化查询第一步从你的健康保险库获取约束“慢性背痛” - 需要腰椎支撑。第二步从你的财务保险库获取约束“预算500美元”。第三步向信任网络通过某个AppView发起查询寻找符合“办公椅”、“腰椎支撑”标签的产品评价。第四步关键AppView在返回结果时会优先展示那些被你所信任的人即你在AT协议中关注的人签名背书的评价。例如你信任的设计师朋友“Alonso”对“Steelcase Leap V2”给出了五星签名评价这条评价的权重会远高于一个陌生人的评价或一条付费广告。这样Dina最终给出的推荐是基于你个人的生理条件、经济条件和你自主选择的社交信任关系综合计算的结果本质上是用一个透明的、由你主导的社交算法替代了不透明的、由平台主导的商业算法。4.7 任务委派让专业的人做专业的事Dina定位为你的个人AI伴侣和数字世界守门人她擅长管理你的个人数据、维护你的社交关系、执行基于信任网络的决策。但对于极其复杂的专项任务如编写一段复杂的代码、分析一份百页的法律文件、规划一个跨国多城市行程她承认更强大的任务代理如OpenClaw、Claude Cowork在纯任务执行能力上可能更优。因此Dina的设计包含了任务委派机制。其工作流是Dina接收你的模糊或高级指令 - Dina利用其人格保险库和信任网络为你细化、个性化指令 - 当指令涉及一个需要高度专业化技能或大量工具调用的复杂任务时Dina会将这个任务封装成一个清晰的规范描述通过安全的通信渠道委派给她所连接的一个或多个专业任务代理去执行- 任务代理执行完毕后将结果返回给Dina - Dina将结果整合进与你的对话上下文并以你能理解的方式呈现给你。在这个过程中Dina始终扮演着“项目经理”和“安全审计员”的角色。她确保委派的任务不违反你的隐私和安全策略通过前述的动作风险控制并负责将专业代理返回的、可能过于技术化的结果“翻译”成对你有意义的回答。5. 实战部署与集成指南5.1 环境准备与独立安装对于想体验完整Dina伴侣功能的用户可以将其作为独立应用安装。目前项目处于技术预览阶段主要面向开发者或有较强技术背景的早期使用者。系统要求操作系统支持 macOS、Linux (x86_64, ARM64)、Windows (通过WSL2或原生Go/Python环境)。依赖Go 1.21 (用于编译核心)Python 3.10 (用于运行大脑)SQLite3 开发库Git安装步骤克隆仓库git clone https://github.com/rajmohanutopai/dina.git cd dina编译Go核心进入core/目录执行go build -o dina-core main.go。这将生成可执行文件dina-core。Go核心负责身份管理、加密保险库、网络通信等所有底层服务。配置Python环境进入brain/目录建议使用venv创建虚拟环境python -m venv venv然后激活Linux/macOS:source venv/bin/activate Windows:venv\Scripts\activate。使用pip install -r requirements.txt安装所有Python依赖这主要包括OpenAI API客户端或其他LLM提供商、必要的自然语言处理库等。初始化身份与保险库首次运行dina-core它会引导你生成24词助记词并创建默认的保险库。请务必安全备份助记词随后核心会启动本地API服务默认通常在localhost:8080。启动Python大脑在brain/目录下配置你的LLM API密钥例如OpenAI的API key到环境变量或配置文件中然后运行主脚本例如python main.py。大脑会连接到本地运行的Go核心API并启动交互界面可能是命令行或未来提供的GUI。实操心得在Linux服务器上部署时建议使用systemd或supervisor将dina-core作为后台服务运行并设置开机自启。对于Python大脑可以考虑使用screen或tmux会话保持其运行。由于涉及加密密钥务必确保部署环境的物理安全和操作系统安全。在技术预览阶段强烈建议仅在测试环境或不包含真实敏感数据的场景中使用。5.2 作为安全层与现有代理集成以OpenClaw为例假设你已经在使用OpenClaw并希望引入Dina作为其安全审查层。目前可以通过“Dina Skill”模式进行初步集成。部署Dina核心按照上述步骤在运行OpenClaw的同一台机器或可达的网络内安装并运行好dina-core服务确保其API可访问。配置OpenClaw调用Dina Skill这需要修改OpenClaw的配置或任务流程定义。具体方式取决于OpenClaw的扩展机制。通常你需要编写一个自定义的“工具”Tool或“技能”Skill当OpenClaw准备执行某个动作时先调用这个自定义模块。实现安全审查逻辑在这个自定义模块中编写代码将OpenClaw计划执行的动作例如“send_email”及其参数收件人、主题、正文封装成一个HTTP请求发送到你本地运行的dina-core的审查API端点例如POST http://localhost:8080/v1/action/review。处理审查结果dina-core会根据内置的风险策略返回审查结果{risk: LOW, approved: true}或{risk: HIGH, approved: false, requires_approval: true}。你的自定义模块需要解析这个响应。如果是高风险且需要批准则应暂停OpenClaw的执行流并通过某种方式如弹出桌面通知、发送消息到特定聊天窗口向用户请求批准。只有在获得用户明确授权后才将控制权交还给OpenClaw继续执行如果被拒绝则向OpenClaw返回一个错误模拟动作失败。集成数据保险库更进一步你可以让OpenClaw在需要用户个人信息来完成任务时例如“帮我订一张从我家到机场的机票”先向dina-core请求数据。dina-core会检查目标数据所在的保险库状态如果需要授权则会触发用户交互。只有用户批准后加密数据才会被解密并返回给OpenClaw使用。注意事项这种集成方式需要对使用的任务代理有较强的定制开发能力。目前这更多是一个概念验证和高级用户的集成方案。项目作者计划未来提供更标准化的钩子Hooks或插件接口以降低集成难度。在自行集成时务必确保Dina核心的API接口不被网络上的其他服务随意访问应通过本地回环地址127.0.0.1或配置严格的防火墙规则进行保护。5.3 参与信任网络要让你Dina的推荐能力更上一层楼你需要主动参与构建信任网络。创建AT协议身份首先你需要在AT协议网络例如使用BlueSky社交网络上拥有一个账户。这个账户将作为你Dina在信任网络中的社交锚点。关联Dina与AT身份在你的Dina配置中填入你的AT协议句柄例如yourname.bsky.social。Dina会使用自己的密钥对在AT协议的PLC中声明这个关联关系。开始签名与关注发布签名评价购买并使用商品后通过Dina的界面撰写评价。Dina会自动用你的私钥签名并将这篇带签名的评价发布到你的AT协议PLC中。公开程度可以设置。关注你信任的人在AT协议客户端如BlueSky App或未来Dina集成的界面中关注那些你认可其品味的用户。这些关注关系构成了你的个人信任图谱。配置AppView在你的Dina设置中指定你希望使用的信任网络AppView地址。你可以使用项目提供的默认AppView也可以输入其他社区维护的、专注于特定领域的AppView地址。Dina在为你进行推荐查询时会使用这个AppView来聚合信息并优先加权你关注者的签名评价。6. 常见问题与排查实录在技术预览阶段的测试和集成中我遇到了一些典型问题以下是排查思路和解决方案的汇总。Q1: 编译Go核心时遇到SQLCipher相关的链接错误。A1:SQLCipher是SQLite的加密扩展需要单独安装其开发库。Ubuntu/Debian:sudo apt-get install sqlcipher libsqlcipher-devmacOS (使用Homebrew):brew install sqlcipherWindows:这是最复杂的环境。强烈建议通过MSYS2或使用预编译的二进制库。更简单的方案是在WSL2Ubuntu子系统中进行开发和运行。安装后确保Go编译命令能找到正确的C库。有时需要设置环境变量如CGO_CFLAGS-I/usr/local/include和CGO_LDFLAGS-L/usr/local/lib -lsqlcipher具体路径根据你的安装位置调整。Q2: Python大脑启动后无法连接到本地Dina核心API。A2:这是一个常见的网络连接问题。检查核心是否运行首先确认dina-core进程是否在运行ps aux | grep dina-core。检查其输出的日志看API服务是否在预期端口默认8080成功启动。检查防火墙/安全组确保本地防火墙没有阻止8080端口的内部连接。在Linux上可以临时用sudo ufw allow 8080如果使用UFW测试。检查大脑配置查看Python大脑的配置文件如config.yaml或.env文件确认CORE_API_URL设置正确通常是http://127.0.0.1:8080。避免使用localhost有时在容器或复杂网络环境下解析会有问题直接用IP地址更可靠。查看核心日志观察dina-core的日志看是否有来自大脑IP和端口的连接请求以及是否有错误信息。Q3: 与任务代理如OpenClaw集成时动作审查API调用总是超时或被拒绝。A3:这涉及跨进程或跨网络调用。网络可达性确保任务代理运行的环境能够访问到dina-core的API地址。如果是本地集成用curl http://127.0.0.1:8080/v1/health测试连通性。API路径和格式仔细阅读Dina项目文档中关于审查API的说明确认请求的HTTP方法POST、请求头Content-Type: application/json和JSON body的格式完全正确。一个字段名错误就可能导致整个请求被拒绝。核心负载如果dina-core处理较慢可能导致超时。检查核心服务器的资源使用情况CPU、内存。在技术预览版中日志级别调高可能有助于发现问题。异步处理动作审查可能需要用户交互弹出确认框这是一个异步过程。你的集成代码不能是简单的同步HTTP调用然后立即等待“批准”结果。需要设计为发起审查请求 - 如果返回“requires_approval”: true则进入等待状态并通知用户 - 在另一个回调或轮询机制中等待最终审批结果。这是一个复杂的集成点需要仔细设计状态机。Q4: 信任网络查询返回的结果很少或为空。A4:信任网络依赖于网络效应早期参与者少是正常现象。检查AT协议连接确认你的Dina正确配置了AT协议句柄并且能够访问AT协议网络例如可以尝试在BlueSky App中发帖看网络是否正常。确认评价已发布通过AT协议浏览器或你的BlueSky个人资料页查看你通过Dina发布的签名评价是否可见。尝试默认AppView确保你配置的AppView地址如https://appview.dinakernel.com是有效的并且服务在线。你可以尝试用浏览器直接访问该AppView提供的公共API端点如果文档有说明看是否能获取到数据。扩大关注范围如果你只关注了很少的人那么基于你信任图谱的个性化推荐池就会很小。尝试关注一些在特定领域如科技、家居、图书活跃且评价质量高的用户以丰富你的信任网络数据源。Q5: 忘记了24词助记词怎么办A5: 这是一个灾难性的问题必须提前预防。无解恢复Dina的设计是彻底去中心化和用户自托管的。助记词是生成所有加密密钥的唯一种子。项目开发者、任何服务器、任何中心化服务都没有备份你的助记词。一旦丢失与该助记词关联的Dina身份、所有加密保险库中的数据因为无法解密、以及在信任网络上积累的所有签名信誉将永久性、不可恢复地丢失。唯一解决方案严格按照安全规范在创建身份的第一时间用笔和纸将助记词抄写在多份防火防水的介质上并存放在不同的物理安全位置如家庭保险箱、银行保管箱。可以考虑使用金属助记词板进行刻录保存以防纸张损毁。绝对不要截屏、不要存放在云笔记、不要通过任何即时通讯工具发送。7. 未来展望与社区共建Dina项目目前处于技术预览阶段已经通过了超过4500项测试但其生态的成熟有赖于社区的共同构建。作为一个开源项目其下一步的发展路径是清晰且开放的。短期路线图协议标准化细化并稳定Dina协议的各部分规范包括身份格式、消息信封、保险库数据模式、信任网络断言标准等争取形成更正式的协议文档。集成便捷化开发更易用的集成套件如为流行任务代理OpenClaw, AutoGPT等提供“开箱即用”的插件或适配器大幅降低作为安全层的集成门槛。用户体验优化完善独立Dina伴侣的图形用户界面使其对非技术用户更加友好简化安装、配置和日常交互流程。长期愿景去中心化MsgBox网络探索将消息中继服务MsgBox去中心化的方案例如通过轻量级P2P协议或利用现有去中心化存储网络如IPFS来消除对单一托管服务的依赖。多模态与主动智能在现有文本交互基础上探索集成语音、视觉等多模态交互能力。并研究在用户授权前提下Dina如何更主动地、恰当地管理个人事务例如智能筛选通知、自动安排日程冲突等。繁荣的信任网络经济愿景是看到一个基于Dina协议的、繁荣的信任网络市场。不同的AppView提供各具特色的数据聚合和排名算法专业评审人通过提供高质量的签名评价来建立信誉甚至可能衍生出基于贡献的激励模型最终形成一个真正由用户和其信任关系驱动的、而非由广告收入驱动的推荐生态系统。对开发者的邀请项目的作者是独立开发者其力量是有限的。Dina的潜力在于社区。我尤其期待并欢迎后端架构师、安全工程师、密码学专家、分布式系统工程师能够深入审查项目代码GitHub仓库完全公开挑战其架构设计进行安全审计并提出改进建议。无论是提交Issue、发起Pull Request还是基于协议实现自己的客户端都是对构建一个更安全、更私密、更以人为本的个人AI未来所做的宝贵贡献。这个项目的成功不在于一个公司的垄断而在于一个开放协议的广泛采用和持续演进。