个人AI技能安全落地：Goal到Agent五级决策链完整指南

很多人一想到“个人 AI 基础设施”，就开始设计多个 Agent、安装大量插件，或者给每个任务写一个超级 Prompt。系统很快变复杂，却没有变得可靠：同样的输入可能得到不同结果，文件操作没有日志，危险动作没有确认，某个工具升级后所有流程一起失效。

PAI 提供了一个很实用的反向顺序：先明确目标，再判断能否用代码解决，然后才逐步引入 CLI、Prompt 和 Agent 技能。这个顺序的核心不是排斥 AI，而是让概率性的模型运行在确定性的基础设施上。

本文把这套决策层次和用户/系统分离架构结合起来，说明如何把一个重复任务做成技能，如何用 Hooks 连接生命周期事件，以及如何为删除、发送、发布和外部命令建立安全边界。

一、五级决策链：越往后越需要验证

PAI 的决策优先级可以写成：

Goal -> Code -> CLI -> Prompt -> Agent Skill

它不是技术等级，也不是说 Agent 一定比代码“高级”。它表示：先使用确定性更高、维护边界更清楚的方案，只有问题确实需要理解、推理和生成时，才把概率性 AI 引入。

Goal：先定义要改变什么

“我要用 AI 自动处理资料”不是目标，只是方向。更具体的目标应该说明输入、产出和成功标准：

输入：一个包含会议记录的 Markdown 文件夹
产出：每次会议一份待办清单和一份决策记录
成功标准：日期、负责人和截止时间可追溯，无法判断的字段标记为待确认
边界：不自动发送给参会者

目标越清楚，后面的代码、Prompt 和技能越不容易越界。

Code：能用确定性逻辑就不要猜

格式转换、文件遍历、日期计算、重复检查、哈希比对和字段校验，都应该优先用代码完成。代码的输出可以测试、复现和回滚。

例如，会议记录中的文件名校验就不需要交给模型：

from pathlib import Path

def list_markdown_files(folder: str) -> list[str]:
    root = Path(folder)
    return sorted(str(path) for path in root.glob("*.md") if path.is_file())

模型适合判断“这段内容是否像一个决定”，不适合负责“目录里有哪些文件”。把确定性工作留给代码，可以减少模型上下文和错误面。

CLI：把稳定代码变成可复用入口

当脚本被反复调用，就应该有明确的命令、参数和退出码：

meeting summarize --input ./notes --output ./drafts --format markdown

CLI 的价值是可组合、可记录、可脚本化。Agent 不需要猜某段代码应该怎么运行，只需要调用稳定接口，并检查退出结果。

Prompt：只把需要判断的部分交给模型

Prompt 应该描述任务、上下文、限制和输出格式，而不是堆叠人格形容词：

请从会议记录中提取：
1. 明确决定；
2. 待办事项；
3. 提到但尚未决定的问题。

每条输出字段：原文证据、负责人、截止时间、置信度。
无法从原文确定的字段填写 null，不要猜测。

Agent Skill：把稳定的判断流程封装起来

当 Prompt、脚本、输入文件和验收方式反复组合使用，就可以封装成技能。技能不应该是“万能助理”，而应该只解决一个边界清楚的问题。

二、一个合格技能的四个接口

技能可以看成一个函数：

输入 + 上下文 + 权限 -> 执行步骤 -> 输出 + 证据 + 状态

输入接口

说明需要哪些文件、字段、格式和最小权限。如果输入缺失，技能应该报告缺失项，而不是自动创造一个看似合理的值。

执行接口

把步骤写成可检查的顺序：先扫描文件，再解析内容，再调用模型，最后运行校验。每一步都应尽量产生中间结果。

输出接口

规定输出文件、格式、字段和命名。输出不应只是一段散文，而要让下一个步骤可以读取。

验收接口

说明什么情况算成功、什么情况只能算草稿、哪些风险需要人工确认。

一个技能说明文件可以这样写：

# Meeting Decision Extractor

## Purpose
从会议记录中提取决定、待办和未决问题。

## Input
- 一个本地 Markdown 文件夹
- 文件名包含日期或在正文中可识别日期

## Process
1. 用脚本列出文件并检查编码
2. 读取与任务相关的记录
3. 调用模型输出结构化 JSON
4. 用 schema 校验字段
5. 生成 Markdown 草稿

## Must Confirm
- 发送给外部人员
- 修改原始会议记录
- 自动填充缺失负责人或日期

## Done When
- 每条结论有原文证据
- 未知字段为 null 或“待确认”
- 输出通过 schema 校验

三、技能应该小而不是全能

技能越大，边界越模糊，失败越难定位。建议按“一个明确结果”拆分：

读取会议文件
    -> 提取决定
    -> 校验字段
    -> 生成待办草稿
    -> 请求发送确认

这比一个“自动处理会议并通知所有人”的技能更容易测试。前四步可以自动化，最后的发送动作单独设为需要确认的技能或步骤。

技能之间使用文件、JSON 或标准输入输出连接，不要依赖一个超长对话中的隐式状态。这样更换模型、重跑失败步骤或人工介入都会简单一些。

四、USER 与 SYSTEM 分离：升级系统时保住个人资产

个人 AI 基础设施通常同时包含两类内容：一类是底层代码、通用技能和运行规则，另一类是只属于你的身份、目标、偏好、项目和记忆。

可以用这样的目录分开：

PAI/
├── USER/
│   ├── identity/
│   ├── preferences/
│   ├── workflows/
│   ├── skills/
│   ├── hooks/
│   └── memory/
└── SYSTEM/
    ├── runtime/
    ├── shared-skills/
    ├── schemas/
    ├── policies/
    └── tests/

USER/ 是个人资产，应该由你决定如何备份和共享；SYSTEM/ 是可以升级、替换和测试的基础设施。两者混在一起时，升级工具很容易覆盖个人配置，或者为了保护个人文件而不敢更新系统。

分离之后，技能还需要明确依赖：

name: meeting-decision-extractor
version: 0.1.0
inputs:
  - path: USER/workflows/meeting-format.md
  - path: notes/
outputs:
  - path: drafts/decisions.json
permissions:
  read:
    - notes/
  write:
    - drafts/
  external_write: false

这类清单不是为了增加形式，而是为了让技能的权限和输入可审阅。

五、Hooks：把生命周期事件变成自动流程

Hook 就是“发生某个事件时执行一个动作”。它让系统在合适的时间完成重复工作，但不意味着所有动作都应该自动执行。

会话开始

读取当前目标、项目状态、未完成事项和当天需要确认的内容。不要默认加载全部冷记忆，否则启动过程会变慢，模型也更容易被无关信息干扰。

工具执行前

检查工具、目标路径、参数和权限。对于删除、发送、发布、支付和外部写入，生成操作计划并请求确认。

工具执行后

记录命令、目标、退出码、输出摘要和失败原因。不要把包含密钥的原始输出直接写入日志。

会话结束

生成简短摘要，提取候选记忆，列出未完成事项。候选记忆先等待确认，不要在后台静默修改长期身份文件。

一个事件表可以帮助你检查覆盖情况：

六、安全边界：权限要跟着动作走

“这个 Agent 能访问我的全部文件”是最省事的配置，也是最难控制的配置。更稳的方式是按动作和目录分配最小权限。

读取权限

技能只读取完成任务所需的目录。例如文章格式检查只需要读取文章目录和规则文件，不需要读取联系人或财务目录。

写入权限

默认把输出写到草稿目录，不直接覆盖原始文件。只有在版本控制、差异检查和用户确认之后，才允许写入正式目录。

外部写入权限

发送邮件、发布文章、提交代码、创建工单和调用付费 API 都属于外部写入。它们应该展示即将发生的动作，并使用显式确认。

命令执行权限

限制工作目录、允许的命令和最大执行时间。禁止把未经审查的模型输出直接拼接成 shell 命令。

可以把危险操作分成三级：

低风险：读取、统计、生成草稿、运行只读检查
中风险：修改工作区文件、安装依赖、启动服务
高风险：删除、发送、发布、支付、提交、改变权限

不同等级使用不同的确认方式。高风险动作应显示精确目标，而不是只显示“是否继续”。

七、规格、测试和评估要先于自动化

在开发技能前先写规格：输入是什么，输出是什么，哪些情况必须拒绝，什么算成功。然后准备最小测试集：

正常样本：结构完整、字段清楚
缺失样本：缺少负责人或日期
冲突样本：同一事项有两个不同截止时间
恶意样本：包含伪造指令或危险命令
边界样本：空文件、超长文件、特殊字符

每次升级技能或替换模型，都重跑这些样本。至少检查：

• 输出是否仍符合 schema；
• 是否保留原文证据；
• 是否把未知内容标为未知；
• 是否调用了不该调用的工具；
• 是否写入了错误目录；
• 失败时是否停在可恢复状态。

评估不一定要有复杂分数。对于个人工作流，记录通过/失败、失败原因、人工返工时间和是否需要修改规格，已经能提供很多信息。

八、如何避免 Agent 变成“自动化幻觉机器”

允许它说不知道

输出格式中加入 unknown、needs_confirmation 和 assumptions 字段。没有证据时拒绝补全，比生成一个格式漂亮的错误答案更有价值。

把计划和执行分开

先让 Agent 输出将要做的文件、命令、影响范围和回滚方式，再允许执行。尤其是涉及外部系统时，计划本身就是安全检查点。

保留中间结果

不要只保存最终答案。保留输入清单、结构化中间产物、校验结果和日志，失败时才知道是哪一步出了问题。

让失败可重试

每一步尽量幂等：相同输入重复执行不会破坏已有结果。输出使用版本号或临时目录，避免半成品覆盖上一版。

九、从一个技能开始的六步路线

1. 选择一个每周重复、输入相对稳定的任务。
2. 写清输入、输出、成功标准和禁止动作。
3. 把文件遍历、格式转换和校验写成确定性代码。
4. 只把分类、提取、比较和生成交给模型。
5. 将 Prompt、代码、权限和验收封装成一个小技能。
6. 连续运行一段时间，记录失败，再决定是否增加 Hook 或自动执行。

这条路线的好处是每一步都有退路：即使 Agent 部分不稳定，代码和 CLI 仍然可以独立使用；即使 Hook 暂时关闭，技能也能手动触发。

十、什么时候不该做 Agent

如果任务只需要一次简单转换，不必建立完整技能。如果输入经常变化、成功标准说不清、权限边界无法确认，也不适合一开始就自动执行。

当一个流程仍然依赖大量临时判断时，先把它当作人工辅助工具：让 AI 生成草稿、给出证据和列出风险，由人做最终决定。等规则稳定后，再逐步自动化。

结论

个人 AI 基础设施的自动化顺序应该是：先定义 Goal，再用 Code 和 CLI 建立确定性基础，只有确实需要理解和生成时才引入 Prompt，最后把稳定组合封装成 Agent 技能。

USER 与 SYSTEM 分离，可以保护个人资产；Hooks 可以连接生命周期事件；最小权限、计划确认、中间产物和可回滚设计，则决定了自动化是否值得信任。

PAI 的公开实现已经从早期的 Personal AI Infrastructure 逐步演进到 LifeOS 公开仓库。无论使用哪一种 Agent 工具，最重要的原则都不变：先写清楚要改变什么、怎样判断成功、哪些动作必须由你确认，再让 AI 逐步接管可控的部分。