V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  bimeixishuai  ›  全部回复第 1 页 / 共 1 页
回复总数  11
@unusualcat 哈哈 太性情了
@Leeeeex 哇,你比我细心
@metalvest
当前版本还不是自动维护,主要是“给材料 + AI 整理 + 生成初始 memory.json”,然后供不同工具读取。
后续维护我还在拆:用户主动改、AI 提建议再确认、以及少量低风险事实的受限更新。
这块弯弯绕绕有点多,还在研究。
别收藏了,快来讨论哇
@DonaldY
你说得对,确实是 skill 这类东西出来以后,我才有了这个想法的。

我真正想做的重点也是把排障经验和步骤固化下来,不是强调 Agent 直接拿线上 DB/Redis 权限。

文里这点我确实写得有点理想化了。真实落地时,更合理的接法应该是走企业内部已经封装好的日志/查询/观测平台,runbook 是上层逻辑,底层不一定是裸连生产系统。

反过来说,我现在也越来越觉得,adapter 层本身未必最难,真正难的是把团队里那些知道先查什么、什么证据算数的经验沉淀下来。
为什么发布前 markdown 格式还没问题,发布完就成这样了
@nachzugler
并不冲突,你这个其实很有参考价值,本质上已经是“memory + 文本知识库 + 工具调用”的一套工作流了。
我现在想验证的点和你这套不完全冲突,而是看要不要再抽一层更小的公共入口,让不同 AI 接手时先拿到一致的用户信息和基础约束。

举例:若是你的 openclaw 挂了,是不是就要请外援介入?比如告诉 cc 或者 codex 让他们帮忙修复,这时候或许就需要一个运维入口,这个入口里有 openclaw 运维过往,坑之类的,知道哪些能改哪些要请求询问。或许比让他们直接读 openclaw 文件夹下的一堆要好。
3 月 10 日
回复了 jedeft 创建的主题 程序员 分享一个高效的开发思路
可以用 gitworker ,切不同的分支并发编程
@jybox
很多内容直接喂文本就够了,尤其是 runbook 、项目状态、规则说明这类内容。
但是结构化会不会更稳定呢?需要验证一下
@touchwithe
我觉得对话交接更适合短期、一次性的上下文传递,不太适合做长期、可复用、可审计的入口。
比如我这几天就在处理一个场景:同样是部署 openclaw ,mac mini 上很快跑通,但 Windows + WSL 踩了不少环境坑。
这些坑如果只留在一次对话里,下一个 AI 接手时还是要重新摸索;如果沉淀成当前机器的运维入口,它就能更快理解这台机器的实际情况。
我现在想验证的就是这层东西有没有必要。
@AoEiuV020JP
你的提醒是对的。
我想验证的其实不只是统一格式,而是把它做成 AI 接手任务时的第一层入口。先读可迁移的用户/记忆信息,再进入具体项目的专属入口。
这样外层是跨项目可复用的,内层保留本机或项目自己的状态、规则和 runbook 。
我现在正用 Codex 和 Gemini 做实验,看切换模型后能不能真的减少重复说明、降低接管成本。
如果最后只是多一个格式,没有实际收益,那这个方案就没价值。
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5653 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 07:43 · PVG 15:43 · LAX 00:43 · JFK 03:43
♥ Do have faith in what you're doing.