bimeixishuai

V2EX 第 739110 号会员，加入于 2025-03-12 10:10:55 +08:00

今日活跃度排名 1013

bimeixishuai 提问技术话题好玩工作信息交易信息城市相关

做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

程序员 • bimeixishuai • 4 小时 31 分钟前 • 最后回复来自 bimeixishuai

你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

程序员 • bimeixishuai • 4 天前 • 最后回复来自 bimeixishuai

» bimeixishuai 创建的更多主题

bimeixishuai 最近回复了

4 小时 31 分钟前

回复了 bimeixishuai 创建的主题 › 程序员 › 做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

@DonaldY
你说得对，确实是 skill 这类东西出来以后，我才有了这个想法的。

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

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

反过来说，我现在也越来越觉得，adapter 层本身未必最难，真正难的是把团队里那些知道先查什么、什么证据算数的经验沉淀下来。

4 小时 54 分钟前

回复了 bimeixishuai 创建的主题 › 程序员 › 做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

为什么发布前 markdown 格式还没问题，发布完就成这样了

4 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

@nachzugler
并不冲突，你这个其实很有参考价值，本质上已经是“memory + 文本知识库 + 工具调用”的一套工作流了。
我现在想验证的点和你这套不完全冲突，而是看要不要再抽一层更小的公共入口，让不同 AI 接手时先拿到一致的用户信息和基础约束。

举例：若是你的 openclaw 挂了，是不是就要请外援介入？比如告诉 cc 或者 codex 让他们帮忙修复，这时候或许就需要一个运维入口，这个入口里有 openclaw 运维过往，坑之类的，知道哪些能改哪些要请求询问。或许比让他们直接读 openclaw 文件夹下的一堆要好。

4 天前

回复了 jedeft 创建的主题 › 程序员 › 分享一个高效的开发思路

可以用 gitworker ，切不同的分支并发编程

4 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

@jybox
很多内容直接喂文本就够了，尤其是 runbook 、项目状态、规则说明这类内容。
但是结构化会不会更稳定呢？需要验证一下

4 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

@touchwithe
我觉得对话交接更适合短期、一次性的上下文传递，不太适合做长期、可复用、可审计的入口。
比如我这几天就在处理一个场景：同样是部署 openclaw ，mac mini 上很快跑通，但 Windows + WSL 踩了不少环境坑。
这些坑如果只留在一次对话里，下一个 AI 接手时还是要重新摸索；如果沉淀成当前机器的运维入口，它就能更快理解这台机器的实际情况。
我现在想验证的就是这层东西有没有必要。

4 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

@AoEiuV020JP
你的提醒是对的。
我想验证的其实不只是统一格式，而是把它做成 AI 接手任务时的第一层入口。先读可迁移的用户/记忆信息，再进入具体项目的专属入口。
这样外层是跨项目可复用的，内层保留本机或项目自己的状态、规则和 runbook 。
我现在正用 Codex 和 Gemini 做实验，看切换模型后能不能真的减少重复说明、降低接管成本。
如果最后只是多一个格式，没有实际收益，那这个方案就没价值。

» bimeixishuai 创建的更多回复