模型出草案，核心落库；Agent 从命令行来干活。
安时和模型之间有两条方向相反的路：一条是你在安时里说一句话，它整理成草案等你确认； 一条是 Codex、Kiro 这类工具从外面来读写安时的任务与日程。 两条路都不让模型碰数据库。
谁调用谁，决定了你要配什么
这两件事在设置里是两块、凭据也是两份，不能为了复用一行版式把它们叫成同一种「接入密钥」。
AI 草案安时 → 模型
你说一句话，安时把它整理成任务或日程的草案。请求从你的机器直接发到你选的服务商，Key 填在你自己的机器上——我们不代管、不中转，也看不到你问了什么。
配置：设置 → Agent → 模型配置
Agent 接入外部 Agent → 安时
在 Codex 或 Kiro 里说「我还有哪些待办」，它直接来问安时，不必自己再存一份清单。 接口只监听 127.0.0.1 并要求 Bearer Token，不对局域网、更不对公网开放。
http://127.0.0.1:19735/api/v1 · ~/.nikou-agenda/agent-token
模型不写库，也不读库。它只出关键词与草案；查库定位、时间算术、冲突检查、落库一律由核心做。 这不是保守——曾经把「明天上午 11 点提醒我」交给模型整理，它给出的时刻是对的，年月是八个月前：那个值格式完全合法，界面按「月-日」印出来还看着正常， 确认之后才发现任务落到了去年一月。
现在「今天下午」这类说法由核心按固定规则算（上午 09:00–12:00、下午 14:00–18:00、 晚上 19:00–22:00），算过就在草案卡上说明；一句话里出现两个日期时不猜、不动。
面板压在你正在看的东西上
点标题栏那颗 AI 把面板收起 / 落下，再点面板里预置的那三句话—— 打字、思考过程、草案卡、确认回执，一轮走完。
没有符合这些条件的任务
数据同步方案定稿进行中
验收对齐新建
预约下周的体检未排期
数据同步方案定稿进行中
验收对齐新建
预约下周的体检未排期
- 01
面板是从标题栏落下来的非模态浮窗，不是一个独立的 AI 页面。 场景决定形态：你正看着清单或某一周的日历，顺口说一句话——面板要压在上面，而不是把你正在看的东西替换掉。
- 02
思考过程把「模型给了什么」和「核心做了什么」分行列清楚。 这不是炫技：模型只出关键词与意图，查库定位、时间算术、冲突检查都标着是核心做的，你才知道哪一部分是可以信的。
- 03
确认按钮说清这一下会发生什么（「加这段排期」而不是「确定」），改字段时草案卡上画出「旧 → 新」。按下去之前，库里什么都没变。
同一套语义，换一种形态
语义逐条继承桌面端，只重排形态——两端语义漂移是最难发现的一类问题，它不报错。
· 解析出标题「同步方案」与截止「下周三」
· 「下周三」= 9 月 17 日，「下午」按固定规则算成 14:00–18:00
· 「半天」= 240 分钟，正好是这个时段的长度
· 查冲突：这段时间里已经有一场会
这段时间和 1 项安排冲突
与「客户例会 16:00–17:00」重叠，写入不会替你改期
已写入· 解析出「和设计过一遍改版」，认成日程而不是任务
· 「明天下午三点」= 9 月 12 日 15:00，时长 1 小时
· 查冲突：15:00–16:00 空着
· 认成查询而不是记事，所以不出草案
· 「今天」= 9 月 11 日，清单由安时查库给出
还有 1 项未列出
- 01
手机上 Agent 是整屏 Tab。 一屏只放一件事，浮窗在这里没有意义。桌面端那两套逻辑因此不移植：模态弹层出现时让位、入口图标带「在想」角标——整屏不会被挡住，进度就在屏上。
- 02
「正在思考」那一行是规范里单列的一条。 一轮要几秒，期间连自己刚发的话都不出现，人会以为没发出去。
- 03
居中那一行不是模型说的，是核心插进历史的注解（「这段时间和 1 项安排冲突」）。所以它两侧都不靠——靠边就会被读成对话的一方。
- 04
查询清单卡长在对话流里，不是屏底一块固定区域。做成「最近一份」的话，问完今天再问明天，卡还停在老地方，读的人对不上是哪一问的答案。每天最多列 4 行，被截断时必须说出来。
- 05
手机上这一屏当前的默认后端是本机确定性解析，不联网、不调模型——它就是「随手记」的会话式延伸。配好模型之后换的是后端，会话流一行都不用改。
规则在服务端，流程在命令行，判断在 Skill
这三句是整套 Agent 接入的全部结构。每一层都有「挪到别处会怎样」，而后果都是 「不报错、只是数据长得不对」。
安时自己规则与约束
排期不许跨自然日、报新段要收上一段、完成时收干悬挂的排期块
挪走的后果：挪进命令行工具就只对「听话的调用方」生效，界面、手机、插件全绕过去，而现象是「同一条规则在 App 里不成立」。
命令行工具多步流程
认领 + 报排期 + 留记录编成一条命令；事后补记的五步编成另一条
挪走的后果：挪进 Skill 文档就变成「四步顺序不能反」这种叮嘱，而模型会漏步——漏步只表现为数据长得不对。
Skill判断
该用哪条查询、要不要接管别人手上的活、结论写什么
挪走的后果：挪进工具里就变成猜用户意图的启发式，而它猜错时没人能纠正。
三个 Skill，跟着命令行工具同版本发布
分开放的后果是版本漂移：文档里写着一条命令，而用户装的那份没有它—— 这种错只会在运行时以「未知子命令」出现。
nuncta-shared
怎么连接、你的身份是谁、失败了怎么办、哪些操作要先问人。另外两篇都引用它，用户不会直接点名它。
nuncta-task
任务、排期块、执行记录、认领与接管、事后补记。「我有哪些待办」和「派给你的任务」是两个不同的问法，这一篇把它们分开写。
nuncta-calendar
日历、事件、提醒，以及把事件、排期块、截止线合在一起的统一 Agenda 时间线。
- 01
装是一键的：Codex / Kiro / Claude Code / Cursor。选好目标点一下，不用你手动复制文件或改配置。值得一键的理由很具体—— 其中一个工具的 Skill 目录名和另外三个不一样，放错的话安装会看起来成功，但那个工具永远读不到它，而且不会有任何报错。
- 02
单篇 Skill 不超过 120 行。它每次对话都被完整读进上下文，体积直接换成 token。细节进 references， 但不许只留一句「详见」——模型不会为了一句「详见」去读一篇长文档， 然后它就按自己的想法实现了。
- 03
参数不写进文档，让模型自己跑
--help。把参数表抄一份进 Skill 等于给自己埋一个会过期的副本，而过期的那份不会报错， 只会让模型拼出一条命令行里不存在的参数。
它回给模型的东西长什么样
nuncta 是单个二进制文件，任务、日历、提醒、Agenda 都走它。输出是给模型读的，所以「长什么样」本身就是接口的一部分。
$nuncta status --pretty
# agent 段是「服务端看到的你」，装完第一件事就是核对它
{
"agent": {
"id": "kiro",
"label": "Kiro",
"session": "1296cc",
"workdir": "/Users/you/work/api"
},
"data": { "service": "nikou-agenda", "apiVersion": "v1" }
}
$nuncta task list --pretty
# 这条问的是「用户自己的全部未完成事项」
# 「派给你的」要加 --mine：手动建的、手机上建的都没有执行者
{ "data": [
{ "id": "t_8f2a", "title": "数据同步方案定稿",
"status": "doing", "priority": "high",
"dueAt": "2026-09-11T18:00:00+08:00",
"assignedAgentId": null },
{ "id": "t_31c7", "title": "预约下周的体检",
"status": "todo", "priority": "low", "dueAt": null }
] }
$nuncta task +execute t_8f2a --label "定稿" --note "查了 schema，要加一版迁移"
# 一条命令三步：认领 → 报一段排期 → 留一条执行记录
# 编成一个命令是因为顺序错了会留脏数据，而模型会漏步
{ "steps": [
{ "step": "claim", "ok": true },
{ "step": "schedule",
"plannedStartAt": "2026-09-11T15:30:00+08:00",
"plannedEndAt": "2026-09-11T16:00:00+08:00",
"previousActiveSettled": true },
{ "step": "note", "ok": true }
] }
# 15:40 报的这一段从 15:30 起：向下对齐到整点或半点
# 向上取整会让它的开始落在将来，那就不算「正在进行」
$nuncta schedule create --task-id t_8f2a \ --planned-start-at 2026-09-11T22:00:00+08:00 \ --planned-end-at 2026-09-12T02:00:00+08:00
# 规则在服务端，不在 CLI —— 界面、手机、插件都不经过 CLI
{"error":{"code":"INVALID_ARGUMENT","message":"排期块不能跨自然日（2026-09-11 → 2026-09-12）。一段做不完就分成几段报，每段落在同一天内；先报一段 30 分钟、之后按进展改它，比一次报一大段准确得多","retryable":false}}
# 拒绝里写了怎么改。模型只认 code，文案是给人看的
exit 2
- 01
stdout 只放数据：一个完整 JSON。进度、提示、警告走 stderr。混在一起会毁掉管道，而调用方是模型。
- 02
失败是结构化的，并且退出码分类（参数错 / 鉴权 / 不存在 / 冲突 / 连不上）。模型只按
code判断，不读文案——文案会变，code不会。 - 03
错误信息要教它怎么改，不是只说哪里错了。「被拒绝时」那一段就是样板：它顺手告诉对方「分成几段报、先报 30 分钟」。
- 04
任何情况下不许崩。 一段调用栈在模型眼里和「服务没起来」没区别，于是它会放弃查询、改去凭记忆补记任务——那比报错糟得多。
命令行工具与三个 Skill 目前随桌面端一起装（设置 → Agent → 一键安装）。 独立的安装包还没有对外开放，所以这一页上不放安装命令—— 想现在就接上自己的 Agent，用设置里那个一键安装就够了。
换了工具、换了会话，痕迹还在
任务不只有「谁建的」，还有「现在谁在干、干到哪一步、从谁手上接过来的」。 点下面的五步，看库里当时长什么样。
（在手机上手动建的，没有任何命令）
手动建的任务没有执行者。Agent 问「派给你的任务」时它不会出现——那两个问法不是一回事。
- 步骤Kiro · ~/work/api15:30
开工：先对齐字段口径，再改迁移
- 步骤Kiro · ~/work/api15:52
查了 schema，旧列没法直接改类型，要加一版迁移
- 接管Codex · ~/work/api16:01
从 Kiro（会话 1296cc）接管
- 结论Codex · ~/work/api16:28
迁移已落地，回放脚本跑通；旧列保留一个版本再删
- 01
「我有哪些待办」和「派给你的任务」不是一回事。 前者是你自己的全部未完成事项，后者只包括执行者是那个 Agent 的。手动建的、手机上建的、插件同步来的都没有执行者，所以按「派给我的」去查会返回一个空列表而不报错。
- 02
状态闭环靠服务端兜底，不只靠文档劝。 Agent 写执行记录时任务如果还挂在「待办」，服务端自动推进到「进行中」——写了步骤就说明已经在干了。
- 03
结论是必填的。 完成与写结论是同一个动作；分成两步的话 Agent 会完成完就跑，这个字段最后永远是空的。
- 04
执行记录只增不改。 单条 2000 字、每条任务 20 条上限，超了直接拒绝而不是静默截断——一段没头没尾的记录比明确的拒绝坏得多。它也不会写进你自己的备注里。
- 05
身份是自报的展示信息，不是鉴权。 它让「哪条是 Kiro 建的」在界面上看得出来，但任何一方都能伪造它——真正的隔离要等按 Agent 发 Token，那还没做。
它不做的几件事
不因为接了 Agent 而多发请求
那个接口是入站的：外部工具来问它。安时自己不会因为装了 Skill 而往外发任何请求，也不含使用统计、心跳与崩溃上报。
Token 是全权的
它能读也能写，所以安全边界很清楚：外部 Agent 能读到什么，取决于你把 Token 给了谁。 不要贴进聊天记录、日志或命令行参数里。按 Agent 分别发 Token 还没做。
手机上没有 Agent 接入
回环接口是桌面端的能力。手机上那一屏是「你对模型说话」，方向相反； 设置里能看到接入状态，但派单入口不在手机上。
没有回调，也没有自动执行
Agent 靠自己来问「派给我的任务」，安时不会主动推给它，更不会替你启动一个工具去干活。 快速记录那一条路永远不调模型，它是确定性的本机解析。