Agent 养成记：从经验中长出技能

作者：秋梵，PowerContext Committer

Agent 做完一个任务之后，除了结果，还能留下些什么？

在前一阵儿的外滩大会上，我针对如何做跨 Agent 的经验或技能传递，分享了 PowerContext 经验（Experience）和技能（Skill）有关的内容。

PowerContext 是一个面向人与 Agent 协作的上下文管理工具，关注工作上下文怎样积累和共享以及如何管理的问题。它可以把项目约定、交接进度、实践经验和操作方法放到对应的工作范围里，让后续接入的 Agent 继续使用。

热知识：PowerContext 是 PowerMem 的重大升级版

为了在分享中能让 Experience 和 Skill 这两个概念更容易理解，我做了一个像素世界地图搭建的小游戏 ------ 即让真实的 Agent 在营地搭桥、接通电源，PowerContext 在中间进行相关记录的保存与把实践整理成经验和技能，随后换新地图、新 Agent，观察这些实践是怎么变成可以让后续的任务继续使用的方法的。

接下来就沿着这次实践，为大家进行拆解和说明。

欢迎大家关注 OceanBase 社区公众号"老纪的技术唠嗑局"。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

一、让 Agent 完成一次真实任务

游戏是从一张营地地图开始的。在这像素地图中 Agent 需要通过给它的相关材料和方法，自行寻找解法搭桥、过河、供电，最后把发电机接到营地的灯上，灯亮了则这个任务就完成了。

在游戏中实际上是调用了 Codex SDK 作为一个真实的 Agent 来跑的。在视频中可以看到 Agent 在营地地图中取材、搭桥、铺设导线并点亮营地灯，整个过程结束后这个任务就结束了。

但此时右侧的方法档案中的技能树并没有点亮，对应显示的正式 Skill 数量仍然是 0。

很明显这次成功实践只是一次成功的执行结果，但并没有沉淀为可复用的经验。

这个时候 PowerContext 就上场了。

二、从任务证据生成 Experience

PowerContext 首先做的一件事情是，将第一次任务做的一些动作和相关信息都保存为了 Source。

2.1 Source 留下当时发生的事情

Source 在这里就是来源记录，比如营地任务结束后的公共规则、初始地图与库存、Agent 的实际动作，以及环境验收结果等都会在 Source 中留下记录，作为后续经验整理的来源依据。

比如搭桥的 Source 记录里，可以找到 Agent 在哪些位置施工；任务结束时，独立的环境检查结果等等。以下就是在 Source 中可找到的环境检查结果记录。

检查项	表示什么	营地任务结果
`bridge_reachable`	另一岸是否可以到达	`true`
`beacon_powered`	目标是否接通电源	`true`
`mission_complete`	整局任务是否完成	`true`

Source 的价值不在于把日志存得更多，而在于给后面的 Experience 和 Skill 留下可回查的依据。 以后看到一条经验，可以重新核对当时的规则、动作和结果，而不是只相信一段听起来合理的总结。

现在 Source 证据已经有了，下一个应该要回答的问题就是，这次实践里有什么经验判断值得留下？

2.2 Experience 把记录整理成判断

在 PowerContext 中将经验固定为四部分：

字段	要说明的内容	用搭桥举例
`situation`	当时遇到了什么情况	河道阻断通路，需要到达另一岸
`action`	实际采取了什么行动	观察缺口，准备材料，逐格搭桥并推进
`outcome`	实际观察到什么结果	通路检查通过，另一岸可以到达
`lesson`	下次可以参考什么判断	先确认河岸和缺口，再按当前条件施工

我很认同这个拆分，只有把适用情况和观察结果一起留下来，后面的 Agent 才有材料判断这条经验能不能用。

PowerContext 会在后台自动的去读取前面已经有的 Source 证据，调用配置好的模型来整理出当时遇到了什么情况、做了什么、结果怎么样等等，保存成待审核的经验候选。

待审核 是个关键词，说明经验生成出来之后，还是要进行人为的核对。

这个是 PowerContext 中的一个设计，而且我也很认同这个设计，一是突出了人机协作的理念，二是生成的经验或 Skill 经过人为的审核之后是会更加的可靠的。

所以只有人为审核批准了之后，才形成正式的 Experience，才能真正的去使用。

当然 Experience 也可以配置成后台定时孵化。同样后台任务也只负责整理候选，不会自动批准，批准的事情还是会交予人处理。

Experience 解决了判断是否可靠的问题。但还不够，PowerContext 还会把这份正式经验继续整理成 Agent 可以采用的 Skill 方法。

三、通过候选审核形成可复用 Skill

平常给 Agent 安装的 Skill，通常会说明某类事情该怎么做，PowerContext 里的 managed Skill 也承担这个角色，它保存了名称、用于发现的描述、完整的指令以及精确的来源关系等等。

小游戏中的营地地图最终会整理出两份方法：bridge-crossing 负责搭桥，power-routing 负责供电。前者告诉 Agent 如何观察两岸和缺口、准备木板并从可达侧逐格施工；后者说明如何识别电源与目标、规划线路，并在完工后验证导电连通。

可以看到视频中先审批通过了 Experience，再根据正式 Experience 生成并进行 Skill 审批。搭桥与供电两个节点点亮后，才表示两份正式 Skill 已经形成。

所以可以看到正式 Skill 的生成逻辑和思路与 Experience 是一致的，先是候选，审批后再成为正式。

在视频中就一共经过了两次审批：

Source 生成 Experience Candidate（候选），审核通过后形成正式 Experience。
正式 Experience 生成 Skill Candidate（候选），再次审核后形成 Skill r1 版本。

每个候选都带有不可变编号的版本号。

plain 复制代码

任务 Source    ↓ 生成经验候选审核并批准 Experience    ↓ 根据正式经验生成方法候选审核并批准 Skill    ↓ 明确读取或导出指定版本交给后续 Agent 使用

这条流程是 PowerContext 中从 Source 到 Skill 的生成路径。

那么 Skill 正式方法有了之后，就可以尝试换不同的地图、启用不同的 Agent 来执行不同的任务，看看是否有使用到前面沉淀下来的方法。

四、同一份 Skill，怎样走进不同任务

游戏的第二阶段换成灯塔和观测站两张完全不同的地图，每张地图都会开启新的 Agent 会话，世界状态和库存重新开始。

新 Agent 会拿到当前地图、当前库存和指定版本的 Skill，而它仍然要通过重新观察河岸、估算材料、选择施工路线，并在完成后调用环境验收。Skill 提供的是处理这类问题的方法，不会把上一局的答案复制过来。

这次养成的是可以继续使用的方法。新任务拿到方法以后，仍然需要判断、执行和验证。

灯塔和观测站各进行了三次独立 Codex 会话，使用的都是两份 r1 版本的 Skill。

从视频中可以看到同一版本的方法在不同任务中的实际采用，PowerContext 保存了 Skill，并通过 pc_skill_read（PowerContext 内部的方法）把指定版本正文交给 Agent，并记录这次读取对应的版本和内容摘要。所以最后都能看到他们使用后留下的新的使用记录，这些也都能成为新的 Source。

五、能查履历的 Skill 树

整理这个过程，把一份 Skill 的来历与后续表现连起来，就有了这棵技能树。

这棵树是小游戏中对 PowerContext lineage 和使用记录的可视化显示，从中间的供电技能的 r1 版本往前找，可以找到营地任务的 Source、整理出来的 Experience，以及对应的审核记录。

往后看，又能找到新地图的灯塔和观测站读取了哪一版、执行了哪些动作、最终有没有通过检查。

我觉得这里比点亮两个节点更有意思。节点背后有来历，也有后续使用情况，之后想完善方法时，就有东西可以翻出来看。

它真正解决的问题很朴素：以后要讨论一份方法是否可靠、哪里需要修改时，团队有具体记录可以核对。于是下一步自然变成：这些使用结果怎样进入 Skill 的下一版？

六、基于使用反馈修订 Skill

其实在 PowerContext 的当前内置流程中，修订 Skill 内容是需要由人或接入的 Agent 进行发起的，PowerContext 没有收到使用记录就自动在后台改版的机制。接入方可以编排何时发起，但仍然要经过候选和审核。

在灯塔和观测站的地图中，Agent 各跑了三次，留下六条供电 r1 的使用记录。但地图和线路长度等需求都变了，我就想把开工前估算材料、完工后核对用料这两件事写得更明确一些，所以对供电 Skill 进行了一次修订。

发起修订时要指定准备修改的那个 Skill 的 Revision 版本，并提供相关的使用 Source，PowerContext 会读取旧版正文和这些证据，调用配置好的模型起草完整的修订候选。

当然可以调用配置好的模型进行修订起草，也可以通过直接提交人工整理好的修改内容成为候选，候选审核通过后，PowerContext 才会在同一个 Skill 身份下创建 r2 版本。

原来的 r1 继续保留，以前采用 r1 的任务记录也仍然指向 r1。

游戏最后山间中继站的新会话明确采用供电 r2，搭桥仍然使用 r1，再完成任务和验收。到这里，方法的修订才有了后续使用结果。

使用记录提供依据，修订形成候选，审核决定正式版本，实际任务再验证采用结果。 这几步连起来，方法才有机会随着实践继续完善，持续的优化 Skill 进行进化。

七、把 PowerContext 接进真实项目

像素游戏只是为了把关系摊开给人看，换到真实项目也是同样的逻辑，可以从一件已经完成、以后还会重复的工作开始。

接入 PowerContext 进行使用其实很简单，只需要三步：安装 CLI，启动 Server，再通过 setup 配置自己当前正在使用的 Agent。

plain 复制代码

# 1. 安装并进入配置向导uv tool install --force "powercontext[cli,server]==1.0.0"powercontext config init --language zh --output .env# 2. 校验配置并启动 Serverpowercontext config validate --env-file .envpowercontext server run --env-file .env# 3. 安装与 Server 版本一致的 Codex 集成powercontext setup codex --ref powercontext-v1.0.0

然后就可以开始玩起来了。