Evilom
7.2 KiB
ZgePwV6s4iMUL0kYiwjcr8ZWnIy
Source: https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy
工作内容概述
1、继续整理之前学习整理的Agent
一、提示词分层
将原本混杂在一起的提示系统拆解为三层独立落盘、互不耦合的规则集：
- 工程层（仓库级）：承载当前代码仓库所需的协作约定，包括项目规范、工具调用协议、领域术语和流程约束，跟随仓库进行版本控制。
- 用户层（个人跨项目）：沉淀个人稳定的使用偏好，例如角色设定、输出风格、常用工作流和底线要求，一份维护，在所有仓库中复用。
- 全局层（产品通用契约）：定义产品全域必须遵守的基线规则，比如安全红线、敏感数据处理策略、输出格式强约束，作为最低限度的兜底保障。 每次会话启动前，不再从混杂的文本中临时拼凑指令，而是按预定的优先级和结构，把记忆、画像、用户片段、项目片段组装成一条边界清晰、无冲突的上下文，注入系统指令。三层各自拥有独立的存储位置和加载开关，变更互不影响。
（一）为什么要这样做
原来的做法是将所有规则全部写入同一个配置文件。这会直接引发四个问题：
- 项目切换成本高：个人偏好与项目规则深度交织，更换仓库时必须手工剥离，很容易残留无关设定。
- 版本审查不可行：工程变更与个人偏好混在一起，进行 PR 审查时无法区分修改来源，也难以判断影响的边界。
- 上下文窗口浪费：大量对当前任务无用的信息被重复加载，挤占模型的注意力资源，同时多条矛盾指令并存，会降低输出的一致性和准确率。
- 长期维护困难：任何一处微调都需要在大量文本中定位，容易产生意外覆盖，导致维护人员不敢轻易改动。 根本原因在于缺乏分层隔离，使得不同生命周期、不同责任主体的规则强行糅合，复用性、可审查性和可控性全部受损。
（二）思路
核心思路是把提示当成一种需要架构设计的资产，而不是一段随意粘贴的文本。 首先，三层对应三种完全不同的变更频率和负责主体。工程层由项目维护者在仓库内直接管理，可以走标准的 Code Review 流程；用户层属于个人配置，应当独立于项目存在，更换仓库时自动挂载；全局层代表产品安全底线，必须集中管控，不能被局部修改轻易覆盖。这种切分天然解决了权限管理和发布流程的问题。 其次，每次会话将分散的记忆和画像进行打包注入，是为了构建一条稳定且可预测的上下文基线。通过规定明确的拼接顺序和覆盖规则，即使来源多样，最终生成的指令也是确定性的，避免模型因指令波动而产生行为漂移。 最后，分层的长远收益在于降低认知负担和维护成本。初期需要搭建加载逻辑，但一旦运转起来，后续新增规则、调整偏好或进行灰度测试，都可以在对应层级内定向操作，不会对其他层造成连锁影响。
二、生成技能的二次提炼
对自动生成的技能，建立了一套会自动触发的维护链路：
- 补充校验与外部加工：每个新技能生成后，自动运行合规检查，补全缺失的参数和触发条件，并可根据配置调用外部脚本进行功能验证，确保不只是能执行，而且执行结果正确。
- 周期性目录整理与合并收紧：定期扫描本地技能目录，识别语义高度近似或功能重叠的技能包，进行自动化或半自动化的合并与去重，将其抽象为更通用的基础技能，抑制目录数量的无序增长。
- 可复用偏好独立提炼：将“代码型技能”（工具调用、自动化流程）和“自然语言偏好”（语气、角色、表达风格）分成两条独立的管理线，分开配置、分别演化。偏好部分会被提炼成轻量的“可复用偏好片段”，其版本、开关和加载策略与技能包完全解耦。 整个流程在会话结束后根据配置自动执行，形成“生长—校验—整理—提炼”的持续维护闭环。
（一）为什么要这样做
直接从对话中产生的技能，天然存在两个显著缺陷：
- 冗余重复严重：模型容易因不同的对话表述而生成本质相同但名称、细节略有差异的技能（例如“查天气”和“获取天气”）。如果不加收敛，技能目录会在短期内快速膨胀，充满功能重叠的包。
- 质量不稳固：这些技能往往缺少完整的参数定义、边界条件处理和清晰的触发规则，处于勉强可用状态。直接投入使用会干扰模型决策，导致输出不稳定或错误。 若不进行二次处理，技能库会迅速从有用资产退化为维护负担，排错和整理的成本将远超其带来的收益。
（二）思路
技能资产的持续集成和持续整理流程，技能需要经过校验和重构才能稳定入库。
将“代码型技能”和“自然语言偏好”拆开处理，是基于两者演化节奏和治理方式的根本差异。技能类似于功能模块，会频繁迭代、合并和抽象，需要严格的版本控制和开关管理；而偏好则更接近用户配置，内容轻量、变化较慢，并且需要在所有场景中保持一致。如果强行捆绑，任何偏好的微小调整（比如修改一句惯用语）都会触发技能包的重新发布和测试，这显然不合理。解耦后，两条线可以按照各自的速度演进，偏好调整甚至不需要触及技能包的版本号。
选择周期性整理而不是实时强制去重，是因为新生技能需要一段观察期。经过几次会话的实际调用和验证，才能更准确判断它是否真的与已有技能重复，以及它的稳定边界在哪里。给予这段缓冲窗口，可以避免过早合并导致有用变体被误删。
😄 经过这段时间的学习和实践，我对 AI Agent 的整体脉络有了比较清晰的把握，几个关键环节的思路也基本贯通： - 上下文压缩：理解了如何在有限窗口内保留高价值信息，通过分层、摘要和裁剪策略，把记忆、画像、项目片段高效打包注入，而不是简单截断或堆砌。 - 技能提炼：掌握了从对话中自动提取、校验、去重和收敛技能的方法，让技能库从“能跑但不稳”进化到稳定可复用，抑制目录膨胀。 - Team Agent 与 Sub Agent：厘清了多 Agent 协作的拓扑结构，明确了主 Agent 如何拆分任务、调度子 Agent，以及彼此间的通信契约和上下文隔离方式。 - 提示词划分：建立了工程层、用户层、全局层的分层治理思路，按变更频率和负责主体解耦，让规则各司其职，解决了混合配置下互相覆盖、难以审查的问题。 这几块串联起来，就构成了从底层记忆管理到上层多智能体协作的完整认知链条。