简单分享下我是怎么花最少的钱，但是又非常重度、高频的依赖 AI coding 的。
我目前的订阅是，最便宜的 copilot 和 codex。这两个的特点在于：codex 是按量付费的，而 copilot 是按次付费的。这个区别是最关键的，如果你更喜欢 cc，那么你可以把本文中的 codex 替换为 cc，一样的逻辑。
而作为 coding，其实工作可以拆分为两大类型，我相信其他大部分文字工作也可以这么拆分：
1. 计划阶段：此时会涉及非常高频交流，但是每次交流的内容都不多，你可以使用 codex 的最高思考模式，写下最核心的关键逻辑
2. 实施阶段：这是广义的实施，包括收集资料、撰写文档、coding、testing、debug 反复调试 都可以视为实施。
copilot 的按次付费，使它成为实施阶段的最佳性价比选择。发送一次 prompt 算一次费用，只要 agent loop 没有结束，期间一切的 tools 调用都不计费。只要通过 prompt 给它输入我们之前和 codex 聊好的 spec，接下来就让 copilot 吭哧吭哧的去把最脏最累但是没有特别高思考难度的活全部干完。
具体怎么让 copilot（我最爱用 gpt-5.4） 能够不中断的，一次性干完最多活，这里面需要调试 copilot 的 instructions，具体就不展开了，各有各的方法。但是我这里推荐一下我的 remote MCP server https://mcp.laisky.com/tools/get_user_requests
其中的这个 get_user_requests tool，相当于是在 MCP 上维护了一个 TODO list，而且是你可以动态编辑的 TODO list。你只需要在 instructions 里要求 copilot 频繁的，在每次子任务结束后，都去调用 get_user_requests，而且必须在连续两次调用 get_user_requests 为空后才能返回。你其实就拥有了在不打断 agent 一次任务的前提下，和 agent 沟通的能力，而利用这个能力，你就可以让 copilot 在一次计费里，干掉尽可能多的活。
举个我的例子，极端情况下，我很可能一天只需要跑 3 次 copilot，中间会停两次是因为我要吃午饭和晚饭，没精力去盯着 get_user_requests 的 requests queue 了。我甚至经常跑出 copilot 的 tokens quota limit，会被停用一段时间，估计很多人可能都不知道 copilot 还有limit 吧😂
Copilot 还有个我非常喜欢的地方是，如果你把配额用超了，它可以自动转为按次计费，每一次请求约为 $0.03 USD，很实惠。
如果你非常有钱，或者公司给无限的订阅资金，可以忽略这一条。和穷人们共勉。
我目前的订阅是，最便宜的 copilot 和 codex。这两个的特点在于：codex 是按量付费的，而 copilot 是按次付费的。这个区别是最关键的，如果你更喜欢 cc，那么你可以把本文中的 codex 替换为 cc，一样的逻辑。
而作为 coding，其实工作可以拆分为两大类型，我相信其他大部分文字工作也可以这么拆分：
1. 计划阶段：此时会涉及非常高频交流，但是每次交流的内容都不多，你可以使用 codex 的最高思考模式，写下最核心的关键逻辑
2. 实施阶段：这是广义的实施，包括收集资料、撰写文档、coding、testing、debug 反复调试 都可以视为实施。
copilot 的按次付费，使它成为实施阶段的最佳性价比选择。发送一次 prompt 算一次费用，只要 agent loop 没有结束，期间一切的 tools 调用都不计费。只要通过 prompt 给它输入我们之前和 codex 聊好的 spec，接下来就让 copilot 吭哧吭哧的去把最脏最累但是没有特别高思考难度的活全部干完。
具体怎么让 copilot（我最爱用 gpt-5.4） 能够不中断的，一次性干完最多活，这里面需要调试 copilot 的 instructions，具体就不展开了，各有各的方法。但是我这里推荐一下我的 remote MCP server https://mcp.laisky.com/tools/get_user_requests
其中的这个 get_user_requests tool，相当于是在 MCP 上维护了一个 TODO list，而且是你可以动态编辑的 TODO list。你只需要在 instructions 里要求 copilot 频繁的，在每次子任务结束后，都去调用 get_user_requests，而且必须在连续两次调用 get_user_requests 为空后才能返回。你其实就拥有了在不打断 agent 一次任务的前提下，和 agent 沟通的能力，而利用这个能力，你就可以让 copilot 在一次计费里，干掉尽可能多的活。
举个我的例子，极端情况下，我很可能一天只需要跑 3 次 copilot，中间会停两次是因为我要吃午饭和晚饭，没精力去盯着 get_user_requests 的 requests queue 了。我甚至经常跑出 copilot 的 tokens quota limit，会被停用一段时间，估计很多人可能都不知道 copilot 还有limit 吧😂
Copilot 还有个我非常喜欢的地方是，如果你把配额用超了，它可以自动转为按次计费，每一次请求约为 $0.03 USD，很实惠。
如果你非常有钱，或者公司给无限的订阅资金，可以忽略这一条。和穷人们共勉。
https://developer.1password.com/docs/service-accounts/use-with-1password-cli/
最近折腾的一件事就是把服务器部署的密钥全部用 1Password 管理了。
以前的做法比较粗糙，我有一个 private github repo 专门存放各种密钥，每台主机上都在固定的位置 clone 这个 repo。
现在我在 1Password 上创建了一个 vault 专门存放这些密钥，然后为每一台主机创建一个 service account，给它访问这个 vault 的权限。每台主机上安装 1Password CLI，并使用对应的 service account 登录，就可以用下面的形式定义密钥了。
对于那些通过环境变量获得密钥的应用，直接使用
如果你不喜欢环境变量，也可以通过 1Password 的 SDK 在代码里直接获取密钥值。
这样做的优点是，可以在 1pwd 的网站上通过吊销 service account 的访问权限来快速撤销某台主机的密钥访问。可惜就是 audit log 仅对 Business 版本可用，还有就是 service account 的权限粒度仅支持 vault 级别，聊胜于无吧，对于个人服务来说至少比裸奔强多了。
最近折腾的一件事就是把服务器部署的密钥全部用 1Password 管理了。
以前的做法比较粗糙，我有一个 private github repo 专门存放各种密钥，每台主机上都在固定的位置 clone 这个 repo。
现在我在 1Password 上创建了一个 vault 专门存放这些密钥，然后为每一台主机创建一个 service account，给它访问这个 vault 的权限。每台主机上安装 1Password CLI，并使用对应的 service account 登录，就可以用下面的形式定义密钥了。
SESSION_SECRET=op://configs/oneapi/SESSION_SECRET
SQL_DSN=op://configs/oneapi/SQL_DSN
LOG_PUSH_TOKEN=op://configs/oneapi/LOG_PUSH_TOKEN对于那些通过环境变量获得密钥的应用，直接使用
op run --env-file=./one-api/b1.env -- <ORIGINAL_COMMAND> 就可以了，1pwd cli 会自动解析这些环境变量并替换成对应的密钥值。如果你不喜欢环境变量，也可以通过 1Password 的 SDK 在代码里直接获取密钥值。
这样做的优点是，可以在 1pwd 的网站上通过吊销 service account 的访问权限来快速撤销某台主机的密钥访问。可惜就是 audit log 仅对 Business 版本可用，还有就是 service account 的权限粒度仅支持 vault 级别，聊胜于无吧，对于个人服务来说至少比裸奔强多了。
1Password
Use service accounts with 1Password CLI | 1Password Developer
Learn how to use service accounts with 1Password CLI.
https://laisky.notion.site/Effective-context-engineering-for-AI-agents-Anthropic-2ddba4011a868170ac2ddd9017afadde?source=copy_link
Anthropic 介绍 context engineering 的文章。
- prompt engineering 主要关注如何撰写 system prompt。
- context engineering 则关注 agent 相关的所有工程问题。
注意力是稀缺的，context 过长，反而会导致模型能力下降（context rot）。
所谓 Agent，就是在 loop 内自动调用工具的 LLM。
context 注入的两种方式：
1. 在推理前，利用 RAG 检索和注入 context（延迟低）
2. 在 Agent 运行的过程中，通过 tools 自动检索和读取（可以 progressive disclosure，信息更准确）。推荐使用类文件系统的信息索引方式，这些文件的路径本身，也包含重要的信息。
long-horizon tasks 的 context 优化工具箱：
- compaction：压缩 context，仅保留关键信息。记忆信息拆分不同的 TTL 层级，然后按照不同的文件路径进行组织和存储。
- structured note-taking：context 外部的记忆工具，如 TODO list
- multi-agent architectures：拆分子任务，coordinator 仅派发任务和接收 sub-agent worker 的摘要。不要试图用一个上下文维护大型项目的全部信息。
Anthropic 还有一篇 Effective harnesses for long-running agents 感觉只是对本文的 multi-agent architectures 的一些实践小经验总结，信息量不多。
👆 prev
Anthropic 介绍 context engineering 的文章。
- prompt engineering 主要关注如何撰写 system prompt。
- context engineering 则关注 agent 相关的所有工程问题。
注意力是稀缺的，context 过长，反而会导致模型能力下降（context rot）。
所谓 Agent，就是在 loop 内自动调用工具的 LLM。
context 注入的两种方式：
1. 在推理前，利用 RAG 检索和注入 context（延迟低）
2. 在 Agent 运行的过程中，通过 tools 自动检索和读取（可以 progressive disclosure，信息更准确）。推荐使用类文件系统的信息索引方式，这些文件的路径本身，也包含重要的信息。
long-horizon tasks 的 context 优化工具箱：
- compaction：压缩 context，仅保留关键信息。记忆信息拆分不同的 TTL 层级，然后按照不同的文件路径进行组织和存储。
- structured note-taking：context 外部的记忆工具，如 TODO list
- multi-agent architectures：拆分子任务，coordinator 仅派发任务和接收 sub-agent worker 的摘要。不要试图用一个上下文维护大型项目的全部信息。
Anthropic 还有一篇 Effective harnesses for long-running agents 感觉只是对本文的 multi-agent architectures 的一些实践小经验总结，信息量不多。
👆 prev
Notion
Notion—The AI workspace that works for you.
A tool that connects everyday work into one space. It gives you and your teams AI tools—search, writing, note-taking—inside an all-in-one, flexible workspace.
