2026-10-10
2026 下半年的时间点，软件开发等非很多具身任务都可以用各种 Agent 来辅助完成。不同 Agent 产品/软件的用户交互约定不尽相同，比如 Skill 存在哪里，对话历史怎么查看。这里以常见 Agent 为例，对此做一个备忘录。
与朴素的 LLM + toolcall 相比，Agent 软件贡献的一个最显著且常见的抽象就是 Skill。技能作为一段文本，要占用上下文长度来加载；Skill 提供了仅在需要时加载技能的框架。
这个动态加载的过程可以手搓，设想一下：只需在你的 agent 一定会加载的、最顶层的 AGENT.md 中给出一个 Skill 的目录/索引，简要描述每个技能是什么，如果需要加载的话具体的描述文件 (如 skill.md) 在哪里即可。（也因此可以套更多层，让 Skill 目录指向下一层的 Skill 目录）
有 AGENT.md，应该已经不用在每个对话中告诉 AI 你的这些 skill 的索引在哪里了；不过亦可依据具体 Agent 的调用约定来标准化。
上面对 "动态加载" 的描述其实基本等同于 OpenAI 对于 Skill 的描述：
Skills use progressive disclosure to manage context efficiently. ChatGPT and Codex start with each skill’s name and description, then load the full
SKILL.mdinstructions when they decide to use that skill.
只不过 Codex 接受的 skill 是自我描述而非由上层 "文件夹" 描述的。它需要符合特定的标准 - 需要是一个文件夹（主要是为了在 skill 中附带一些 artifact 文件），其中的 SKILL.md 文件包含一个 YAML frontmatter，包含 skill 的名称和描述，它们会无条件预加载到 Agent 的上下文中
---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---
[Skill instructions]
从哪里找 skill：以最常用的用户作用域的 skill 为例，这些 skill 依据约定放在 $HOME/.agents/skills 文件夹下。依据你的 CWD，加载 $CWD/.agents/skills；依据是否在 Git 仓库中，加载 $REPO_ROOT/.agents/skills；诸如此类，全部预加载。
何时调用 skill：主动调用，既输入 $skill 来依据名称索引或者 /skills 内置指令选择。自动调用，Agent 自身也会依据具体情况匹配它所预加载的 skill 的 name 和 description，从而决定是否加载特定的 skill。
兼容 Codex 标准，允许文件夹形式的 skill 也允许单个文件形式的 skill。同样使用 YAML frontmatter 定义一些关键的域，如 description。
Skill 的资源定位方式和调用时机基本兼容 Codex，不再详述。
我们一般不希望 Agent 在工作的时候每隔几秒就要请求权限执行一些命令 - 因为其中大部分 Agent 需要的命令都是只读和/或可以划定安全边界的。依据你使用的具体的 Agent 的约定配置好权限，能让工作流更高效。Coding Agent 早期比较需要手动设置权限，不过近来 Agent 自带的默认值越来越合理，以至于手动调整权限变得越来越不必要了。
每个 Agent 配置权限的地点不尽相同就不列举了，不过一般都是基于配置文件的。
工具调用的细节和结果，比如执行的命令行命令和输出，读取文件读到的具体内容等等，一般不会在交互窗口中持续显示。然而，这些信息对于了解 Agent 到底看到了什么，是怎么干活的至关重要，比如需要审计或者调试时。
所以如果 Agent 自带以人类可读的格式显示或者导出这些内容的方法，那是很好的。其实第三方工具很可能可以很好地完成这个任务（就不在这里列举了）。
（还有一种审计或者调试方式是不导出，直接去找会话数据存储在本地的哪里，然后用第三方工具去去读）
Kimi 在这方面做得最好。在交互式窗口中，可以用 Ctrl+O 来控制是否显示具体的工具调用及输出或者 compact summary。内置的 /export 命令也支持包含工具调用结果并导出至 Markdown 文件。
Kimi 会话的存储结构（文件夹）是有良好规约的，位置则默认在 ~/.kimi-code/sessions/。可以通过 kimi export <sessionId> 导出会话文件夹。
一般的导出，也就是 /export，一般不会包含工具调用及其输出。
--verbose 选项可以让交互窗口展示工具调用和输出。对于你还能 resume 的 session（因此包括当前 session）。claude --verbose [--continue] 然后手动复制交互窗口中的文本可以当成 "导出" 工具调用的一种迫不得已的选择。注：即使使用了 --verbose，也未必能够显示全部工具调用。
Codex 本身是开源的，它近来才支持了 /export 命令导出会话记录到 Markdown（2026.3 的版本不支持，2026.10 的版本已支持）。由于是刚刚更新，命令尚未被收录进入文档，询问一些 AI 工具 Codex 是否支持导出，可能会获得回答 "Codex 不支持导出"。
本地存储的会话数据当前版本在 ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl）。
上面提到的 "权限" 就是基于配置文件的。Coding Agent 作为一种用户可以安装的应用，作用于特定的项目文件夹，又可能受到用户所在的组织管理，因此配置和权限就自然有了多个的作用域：
User scope 用户作用域，适用于用户的所有项目
Project scope 项目作用域，仅适用于一个项目文件夹或 Git 仓库（可能被 Git 提交）
Managed scope 组织管理的配置，适用于组织管理的所有用户
Claude 文档 比较详尽地演示了这些作用域的范围。这是开发工具的共通机制（比如 VSCode 的 User settings 和 Workspace settings）。
有多个作用域，配置之间就有优先级的问题。以 Claude 为例，优先级是 Managed Scope > CLI Config > Project Scope > User Scope。
仅以交互式使用为例（不包括让 agent 后台连续运行数小时完成任务的用例）
确实可行，比如我就试过让 Antigravity 解释它的 Worktree 功能是怎么用的，什么是 Git worktree。不论是否是开发者，都对这个方法颇为好评。
effort 未必越高越好。在一些交互性强的任务中，agent 并没有且无法掌握全部信息：比如你没有意识到需要提供它，或者需要你批准并手动以你的用户身份运行高权限级别的调试命令。这时一轮对话能推进的进度是基本相同的，高/低 effort 都够用；但 effort 高意味着 agent 在回复你之前纠结更长的时间，一个任务反而需要花更长的时间（以及更多的 token）才能完成。
同样是出于任务延迟的考虑，Agent 推理 API 服务的延迟也应该像模型能力、Token 成本一样纳入考量。
通常的想法是 Agent 来做，用户来校验。但 Agent 做完了，用户对项目实现细节的理解是有限的，Agent 采用的方法可能符合写下的规定，但仍然在细微之处不符合最终的需求或者有预期之外的行为。
另一种方法即人来做（仍然用 Agent 辅助调查和编写代码，不过不会让 Agent 自主生成大块内容），阶段性地让 Agent 来校验。这种方法牺牲了人类时间投入产出比的上限，但能够保证人对于项目的理解和控制。
归根结底，判断标准在于人对于领域是否足够熟悉，以至于能快速、深入地理解 Agent 生成的内容。
是，则两种方法中 Agent 和人都能理解项目在干什么，第一种方法更优越。
否，则第一种方法是只有 Agent 彻底理解项目，人不能理解；第二种方法是人和 Agent 都理解项目。变成项目推进速度和项目可靠性之间的权衡。