English TL;DR: A reliable personal assistant is an engineering system. Treat messaging, cron jobs, memory indexing, secrets, and security boundaries as first-class components.
很多人第一次搭“个人助理”会以为：
- 接上一个消息渠道（Telegram/WhatsApp）
- 能回答问题
就结束了。
但当你真的开始把它用于日常工作，你会遇到更硬核的问题：
- 它能不能稳定跑几个月？
- 出问题时你能不能快速定位？
- 它会不会乱发消息、乱改配置？
- 你有没有一个“我知道它在做什么”的闭环？
如果你想要的是一个长期可用、可控、可维护的个人助理，我建议你用“系统工程”的视角搭它。
下面是一份我现在认为最小可用、但足够稳的蓝图。
1) 消息入口：只选 1 个主入口 + 明确权限边界
建议：先用 Telegram 做主入口（调试成本低、速度快）。
关键不是“接入”，而是：
- 谁可以 DM 你
- 群里是否必须 @ 才响应
- 哪些操作算高风险（需要额外确认）
最小策略：
- DM allowlist（只允许你本人）
- 群聊 requireMention=true（不打断群聊氛围）
- 仅你本人允许 elevated tools（比如 exec）
2) 定时任务（Cron）：把“提醒”和“执行”分开
大多数自动化失败，来自“把 cron 当成魔法”。
我建议把 cron 分成两类：
A. 提醒型（systemEvent）
- 只提醒“该做什么”
- 不直接做高风险动作
例如：每日 22:30 提醒生成运营日报。
B. 执行型（agentTurn）
- 真正去跑脚本/发消息/写入外部系统
- 必须有节流、幂等、失败重试
例如：每小时一次的 X 自动发推（带随机抖动）。
原则：提醒可多，执行要少且可控。
3) 记忆系统：让“可检索”比“看起来聪明”更重要
一个好的记忆系统不是“自动记住一切”，而是：
- 关键偏好/决策能长期保存（写入显式的 memory 文件）
- 历史对话能被语义检索召回（sessions 向量化）
- 有定期 reindex，避免索引落后
最小实践：
MEMORY.md：放长期规则（偏好、决策、权限策略）memory/YYYY-MM-DD.md：放日常日志- sessions 全量索引 + 每日自动
memory index
这比“纯靠模型上下文”稳定得多。
4) 凭证管理：统一收口到 .secrets，避免到处找 token
最容易失控的是凭证：
- token 写在环境变量里
- 写在脚本里
- 写在某条聊天记录里
最小可用策略：
- 所有 token/key 统一放到项目的
.secrets/目录 - 遇到权限失败先查
.secrets - 输出/日志严格避免回显密钥
如果你把它当成“工程约定”，长期维护成本会大幅下降。
5) 安全边界：公网机器也要把控制面留在 loopback
如果你的机器有公网 IP，最重要的一条是：
- 控制面板/控制端口只绑定 127.0.0.1
需要远程访问时：
- 用 SSH 端口转发
- 或者用可信的 tailnet（比如 Tailscale）
不要图省事把控制台直接暴露到公网。
6) 最后：你要一个“日报/周报”，否则系统迟早失控
我非常建议你强制要求个人助理每天产出 1 条总结：
- 今天它做了什么（cron 执行、发了哪些内容）
- 做这些事的依据是什么（调研点/判断点）
- 有哪些失败/异常（比如 401/429）
- 明天的候选任务/选题池
自动化不怕执行，怕的是不透明。
如果你已经搭了一个雏形，我建议你现在就做两个动作：
- 把凭证统一收口（
.secrets） - 加一个固定时间的日报
它们的 ROI 会远高于“再接入一个新平台”。
RELATED