Gini Agent：把运行时当作系统记录的个人代理

它要填的是代理跑起来之后的那段空白

多数个人代理项目停在能对话这一层。你给它一个问题，它回一段文字，会话结束，状态散落在日志文件和内存里，第二天再问它昨天做过什么，它不记得。Gini Agent 的定位很明确：对话只是交互面，运行时才是一切记录的系统。README 把这句话写得很直白，runtime 是 conversations、runs、tasks、approvals、memory、skills、jobs、tools、traces、audit events 和 runtime health 的记录源。

这意味着它的目标用户不是想快速拼一个问答机器人的人，而是想让代理持续干活的人。代理会跑定时任务、推进多步工作、跨工具取数，这种代理一旦失控就很难收拾，所以它必须随时可被叫停、可被审查。Gini 把审批、追踪和审计事件放进运行时，而不是留给外部日志系统，这是一个有代价的选择：你获得了统一的状态视图，也把状态锁在了这套运行时里。

一个 Bun 进程同时是网关和执行体

架构上它压缩得很彻底。每个实例一个 Bun 进程，这个进程既持有状态，也实际执行工作。README 给出的图里，网关在上方，下面挂三类客户端：Next.js BFF 承载浏览器 UI、CLI 与脚本用 bearer token 直连、移动端与 MCP 和消息桥走同一套认证过的 /api/* 契约。

有一个细节值得注意：浏览器 UI 不持有 token。Next.js 那一层被标为 no browser token，也就是凭据留在服务端，浏览器只跟 BFF 说话。这个设计减少了 token 泄漏面，但也意味着 BFF 是必经之路，绕过它直接打网关需要自己带 token。

并行实例是另一个实际能力。多个实例各有隔离的状态、端口和日志，所以你可以在一台机器上跑几套互不干扰的代理。文档把端口和磁盘布局写在 docs/gateway.md 里，部署前应该先读那一页，否则很容易在端口冲突上浪费时间。

代理需要你时，给的是控件不是一段说明

这是 Gini 与同类项目差别最大的地方。多数代理卡住时会输出一句话，让你自己去某个地方补一个密钥或者点一个确认。Gini 的做法是在对话里直接渲染可交互控件，然后等。

密钥类字段走的是安全卡片，README 明确说它直接流向网关，不进入模型、不进入对话记录、也不进入审计轨迹。这一点如果属实，解决的是长期存在的凭据污染问题：过去你把 API key 贴进聊天框，它就永久留在了上下文里。

另外三类控件分别是：任务撞上登录墙时，代理把自己浏览器的实时视图交给你，你登录完它接着跑；有多条合理路径时，它给出一个小范围选项让你挑，而不是自己替你决定；在替你发消息、回复、发帖或下单之前，它先展示将要发生什么，再给一个发送按钮。这些设计意图都写在 docs/adr 下的 ADR 里，包括 user-choice-prompt、user-confirmation-primitive、browser-fill-secret、chat-credential-provisioning 和 browser-connect-handoff。

同一套卡片在网页端和 iOS 端由同一个协议渲染。这是个务实的选择，新增一种控件只需要改一处。但它也把移动端绑在了这套协议上，独立演进的空间有限。

安装路径与需要先想清楚的配置

官方给出的安装方式是一条 curl 管道：

curl -fsSL https://raw.githubusercontent.com/Open-Curiosity/gini-agent/main/scripts/install.sh | bash

在 macOS 上，安装脚本会启用开机自启（运行时和 webapp 各自一个 per-user LaunchAgent），等 webapp 起来，然后打开 /setup 页面。表单里提供完整的提供方目录。

模型提供方覆盖得比较宽：Codex 走 OAuth；OpenAI、Azure OpenAI、DeepSeek、OpenRouter 用 API key；Anthropic 走第一方 Claude API；Amazon Bedrock 用模型无关的 Converse 加 AWS SigV4，支持 Claude、Nova、Llama、Mistral、DeepSeek；以及任何 OpenAI 兼容的本地服务器。每个提供方的凭据、前置条件和 CLI/网页配置分别写在 docs/providers/README.md 指向的单独页面里，配之前应该按那一页走，而不是照搬另一个提供方的步骤。

本地嵌入、重排和语音消息转写默认开启。默认本地意味着不需要额外调用外部服务，代价是首次使用会有模型下载和本地算力占用，具体开销文档没有给出数字，这一点需要自己在目标机器上观察。

容器化部署有单独一页 docs/deployment-docker.md，说明如何在 Xvfb 下跑一个带真实浏览器的无头实例。需要浏览器接管登录的场景，这个配置是前提。

记忆与技能学习：两级奖励加人工闸门

记忆部分在 docs/memory.md，关键词是 retain、recall、embeddings、reranking、review 和 storage。从命名看，写入和召回是分开的两条路径，中间有重排环节，还有一个 review 步骤。review 的存在说明它不是无条件把一切塞进向量库，而是留了一道筛选。

技能学习在 docs/skill-learning.md，README 的描述是从任务结果中改进自身技能，机制包括两级奖励、归因、每日复核和人工闸门。两级奖励加归因的组合，通常是为了区分一次任务整体成功和其中某个具体步骤的贡献，避免把功劳记错地方。

人工闸门是这套设计里最关键的约束。它意味着代理不会在无人值守的情况下自行改写技能库，每天有一次复核。对想要完全自主的代理的人来说，这看起来像减速带；对需要知道代理学会了什么的人来说，这是唯一能让技能库保持可解释的方式。

这里要说明的是，文档只描述了机制的存在，没有给出奖励函数的具体形式、归因算法或复核的判定标准。要判断这套学习是否真的有效，只能读 docs/skill-learning.md 原文并在自己的任务分布上观察。

它不适合谁，以及 OpenClaw 迁移这条路

最明显的不适配场景是：你只想要一个能调用的对话接口。Gini 把对话、运行、审批、记忆、技能全部纳入运行时，如果你不需要这些状态，这套结构只会增加你要理解的组件数量。安装脚本还会在 macOS 上装自启动项，对只想试一下的人来说，这个副作用不小。

第二类不适合的是无法接受代理持有文件和终端权限的人。审批门控的文件、终端和代码工具是它的核心能力之一，去掉审批它就退化成一个普通聊天界面，保留审批就需要你持续在场做决定。

第三类是网络环境受限、又不打算配隧道的场景。网关默认是认证过的 localhost，远程访问需要显式配置隧道，文档给了 Gini Relay、Tailscale、ngrok、Cloudflare 四种，每种一页。隧道模式还涉及确认流程。如果你希望开箱即用就能从外网访问，需要先把这一页读完。

对于已经在用 OpenClaw 的人，仓库里有一页 docs/migration-from-openclaw.md，说明如何把现有安装导入 gini。这是它相对同类项目的一个实际优势：迁移路径被写成了文档而不是留给你自己摸索。但导入涉及状态映射，导入前应该先确认哪些数据会被带过来、哪些不会，文档之外的部分不要假设。

维护成本与许可

项目采用 MIT 许可。这意味着你可以修改、分发、商用，代价是保留版权声明和许可文本。这里不构成法律意见，实际使用前应自行确认依赖树中其他组件的许可是否兼容。

版本节奏从发布记录看是 v0.1.0 到 v0.2.0 隔了约两周，v0.2.0 到 v0.3.0 隔了约五天，都还在 0.x 阶段。0.x 意味着 API 和行为可能变动，升级前应该读 docs/releases.md 里关于版本号和 CHANGELOG 约定的部分。

日常维护的负担主要来自三处：提供方凭据的轮换与配置、本地嵌入与重排模型的更新、以及技能复核这个每日动作。第三项是持续性的，不是一次性的。如果你不打算每天花时间看代理学到了什么，人工闸门就会变成积压的待办。

诊断方面，docs/operations.md 覆盖了安装、启动、停止、smoke、诊断和清理。遇到问题时从这一页的 smoke 和诊断命令入手，比从日志文件里翻要快，因为运行时本身就是状态的记录源。

编辑结论

适合已经有一台常开的机器、希望代理长期驻留并保留可审计状态、且愿意接受审批门控的个人开发者或小团队。不适合只想要一次性对话脚本、或者不愿意让代理持有文件与终端权限的人。上手前先确认三件事：网关默认只监听 localhost 且需要 bearer token，远程访问必须显式配置隧道；本地嵌入、重排和语音转写默认开启，模型提供方的凭据要按 docs/providers 逐个配；技能学习有每日复核和人工闸门，意味着它不会在无人值守下自行改写技能。先跑 scripts/install.sh 走完 /setup，再用 docs/operations.md 里的 smoke 与 diagnostics 命令确认运行时健康，最后决定要不要接隧道。

官方来源

1. Issues
2. License: MIT
3. Open-Curiosity/gini-agent on GitHub
4. README
5. Releases