 |
1
maolon 1 月 30 日
有意思， 所以他的意思就是把 agent 的 workfow 应拆净拆到一个 atomic 语义的步骤然后把各个步骤固定化和容器化以应对 scale 和不确定性问题？
|
 |
3
d0r1an OP |
 |
4
Reminders 1 月 30 日  2
agent 执行环境的不隔离，执行过程产生的副作用的确是现实问题。
如果把 skills 和执行环境打包，做到无外部依赖、无副作用、可重用、规模化。也许是个不错的方向。 |
|
6
Reminders 1 月 30 日
@d0r1an #3 我没太明白这个怎么使用，是在 python 中调用这个 SkillBox 么，这个 SkillBox 是不是也应该像 docker 一样提供一个打包好的 image 呢？
|
|
7
d0r1an OP @Reminders 这个 skill 是跑在微型虚拟机里面的，独立内核。目的是让 agent 或者 app 调用，例如文章提到的 buy coffee skill
|
|
8
Reminders 1 月 31 日
@d0r1an #7 意思是，如果把项目部署在服务器上，我想为每一个用户分配一个 skill_box ，那么每个用户都可以通过
boxlite.SkillBox() as skill_box 创建一个 skill_box 使用是吗？无法服务重启，用户可以无负担在再次创建出一个 skill_box 重新使用嘛？ |
 |
9
Cbdy 1 月 31 日
有趣的思路
|
 |
11
liuchao719 8 天前 1
和我之前的一个想法特别类似，agent 现在要处理的逻辑层次太多了，每一层都会带来不确定性。或许还有一种思路是，每次遇到不确定性就分配一个 subagent 处理不确定性。因为与其手动封装各种可重入节点，不如让 llm 自己去划分任务的逻辑层次。
|
|
12
d0r1an OP @liuchao719 可以一起讨论下，精进整个思路和实现
|
|
13
liuchao719 4 天前 via iPhone
@d0r1an 之前不是有人指挥好几个 Agent 干活，人只需要像自己有点像 leader 一样规划就行。其实这个思路是把 agent 作为 leader ，让他去安排一些子 Agent 去做细分的活儿。这样子，Agent 就能够自己去处理一些不确定性的东西，减少了上层 Agent 的一些认知负担。可以嵌套两三层这种架构，专门拆解复杂问题。但我这个想法应该是去年的，现在应该已经有类似的 Agent 架构出来了，只是我还没时间去研究。
然后最近不是 skill 很火嘛，然后还有那种自学习的 skill ，其实对于一个层级上的子 Agent 来说，如果每次划工分给他的问题是合理的，那么我觉得他很快就能自学习出一整套 skill 来，其实很像公司的架构了。 |
|
14
d0r1an OP @liuchao719 Interesting insight 。我琢磨下
|
|
15
liuchao719 3 天前
@d0r1an 我有了一些新想法：
理想状况下 Agent 是一定要完成任务的，但是考虑到现实情况，有可能我们也不能清楚 Agent 能不能完成任务，只是先把任务交给它试试（比如大部分不懂技术的人用 clawdbot 的时候）。这时我们不是想让 Agent 一条路走到黑，然后告诉我他干不了，而是希望 Agent 在执行的过程中，如果过于困难，就向上请求支援。 这个机制还可以应用在多层 Agent 架构中。面对复杂问题，首先分散出一堆子 Agent 探索，子 Agent 如果过于困难，则向上汇报，主 Agent 再根据子 agent 执行结果，综合评定最小解决代价后继续灵活改变计划，或寻找其他解决方案。 |
|
16
liuchao719 3 天前
目前无论是我自己用 AI ，还是观察别人用 AI ，都有一个核心问题：当前 AI 无法感知到所有执行环境。比如一个 API 不通，究竟是网断了？还是梯子挂了？还是服务有问题？可能我们刚好忘记告诉它了某个事实，导致它在执行的过程中一遍遍尝试，浪费很多 token 和时间。但如果 AI 能够“浅尝辄止”并向上反馈，再结合自总结 skill 的机制，把人类的反馈记下来，我觉得 AI 未来应该会是很好的助手/帮手，而非仅仅是一个高效率的执行者。
|
|
17
d0r1an OP @liuchao719 👍 这就是真正的 AI 同事，AI 实习生，遇到不懂的事情要知道向 mentor 求助
|
Select Language