现在基本都是 100% cc 写代码了。也用过 superpowers 之类的牛逼哄哄的 skill 。现在基本每几天就能看到一个自动做 multi-agent 项目的框架，skill ，产品，都疲劳了。个个描述的都很科幻，启动一堆机器人帮你干活，你就一边歇着去。具体使用起来的感受一言难尽。发现都是等几个小时，然后写出来是一个 UI 看起来确实是我刚刚开始说的东西，但是内部是一坨
而且这些 multi-agent 框架现在都在比谁更智能，使用者可以完全不用动。但是程序员是不喜欢这种感觉的，程序员是喜欢透明的。因为我们知道天上不会掉馅饼。低代码框架这么多年也没推开，就是因为那玩意做个简单的不怎么改的小网站，小商城确实是可以。但是你要放公司层面这么搞，最后改 bug 的不还是自己。
我觉得现在 ai 编程最大的问题就是模型会飘，就跟游戏传声筒一样，最后一个人复数出来的话跟第一个人说的完全对不上。如果你启动一个 agent 它可能飘 1 步，你启动多个 agent ，agent 跟 agent 还是上下游关系的话，最后，飘到 100 步开外都不止
 |
1
lolo1 12 days ago via Android  6
复议，所以不明白为啥很多人还在开发什么基于角色的流程 agent ，毫无意义。信息在传递过程会无限失真，一个 cc 能搞定就不要用多个乱七八糟的 agent
|
 |
2
wonderfulcxm 12 days ago via iPhone
用 muti-agent 的场景是什么？我很好奇。
在 ui 这里，是多个 agent 同时设计不同的页面吗？ |
 |
3
ximaoyang OP @lolo1 是啊，而且宣传的例子都差不多，开头就是一句“我想做一个网上商城”然后模型就 ask 你要怎么做啊，要什么架构啊，然后生成一份超长的 SPEC ，然后吭哧吭哧的开始干。
但是哪家程序员是这么干活的。我们不可能从 0 开始做一个网上商城。我们都是在维护一个已经用了很多年的系统，然后每天从 jira 上拿 ticket 下来做。每个 ticket 基本都是给这个购物车加个 xxx 功能。给用户评论加个啥之类的，偶尔会来个大的，比如加个新的模块，这就够大了。 当然你可以把小 ticket 丢给 superpowers ，它也可以帮助拆解，然后丢该子 agent 。但是我发现这就是杀鸡用牛刀，写出来的还是一坨，我只能打断它让它不要去提交代码，我先看一遍。然后发现这都没必要用这玩意。直接把 ticket 用 cc 自己分析一下，然后让 cc 写完别提，然后自己审核一下，虽然慢，但是之前 superpowers 写的那是啥玩意。 |
|
4
ximaoyang OP @wonderfulcxm 就是需求拆解，然后去做
|
 |
5
ota 12 days ago
那有专门做规范层的 skill 嘛？推荐推荐。我也想知道怎么保持统一性。
agent 生成时严格按照 Schema 结构定义，不然回滚重新来。然后加个全局约束作为锚点。 为了防止 agent 对上下游的自然语言依赖，这一层要清洗成 Schema 。agent 之间禁止传送自然语言？这样指数飘就能缓解不少了。但工程实践具体怎么个 flow ，还有待 op 实践分享。 |
 |
7
GeruzoniAnsasu 12 days ago 1
> 我觉得现在 ai 编程最大的问题就是模型会飘，就跟游戏传声筒一样，最后一个人复数出来的话跟第一个人说的完全对不上。如果你启动一个 agent 它可能飘 1 步，你启动多个 agent ，agent 跟 agent 还是上下游关系的话，最后，飘到 100 步开外都不止
本质在于 LLM 的输出即思维。这是一个类似不确定性原理的模型 —— 想要观测模型思维就必须让它输出，想让它输出就必须先有输入，有输入就会干扰其输出权重。结果就是，你无法同时获得（ LLM 对概念的精确理解|LLM 对概念的自主思考）。这两个共轭量的「乘积」整好反应了模型的底层实力，有这个基本原理存在决定了不可能用外部治理的手段把模型能力提升到更好模型的水平。 > 个个描述的都很科幻，启动一堆机器人帮你干活，你就一边歇着去 但凡做过真实产品的人都知道这「从信息论的意义来说」就不可能。所以自动化 agent 产品的核心价值在于怎样定义最适合 agent 发挥，同时人类能最好、最简单掌控局面的协作模式。其实绝大多数产品都没在尝试除了「让 AI 根据 prompt 放手干」之外的模式，效果必然都在同一个不尽如人意的水平上晃荡。 |
|
8
ximaoyang OP @GeruzoniAnsasu 共轭量的「乘积」。我去，专业人员
|
 |
9
xialaoban 12 days ago
尝试过 subagent/muti-agent 直接工作，也试过 cc 指挥/codex:rescue 多 agent 工作，superpowers 会要求很小的实现，配合多 agent 确实看起来很嗨，但我真的没感觉到效率提升，也没有大家宣传的可靠性。
全新项目和旧项目维护，改到最后都会变成一坨屎。。。 大量代码我看不过来，又只能让 agent 自己 review ，它又抓不到重点，还经常丢三落四。。。 和几年前比起来依旧是上下文丢失的老问题，写着写着就不再主线上了，总是钻进小细节无限套娃 |
|
10
ximaoyang OP @GeruzoniAnsasu 确实是，我就觉得这不可能嘛，我自己都知道我给的信息不全，它是怎么做出来的，无中生有
|
|
11
ximaoyang OP @xialaoban 我一直觉得 agent 自己 review 自己是一个骗局。agent 它写的代码没有小问题只有大问题。开另一个 agent 来审核，大问题它又看不出来，小问题不用它看。纯浪费 token
|
|
12
ota 12 days ago
@ximaoyang https://docs.piebald.ai/ 这个也许有点意思，可以尝试尝试。
我看了几个功能挺不错的，我也刚上手。 Agent rules Permission modes Pausing the agentic loop Context management Subagents Tool calls + Builtin tools Default system prompt Using @pierre/diffs for file edit diffs ✓ Branching 工具我觉得也就这极限了，llm 底层结构决定了漂移的必然性。 |
 |
13
getadoggie 12 days ago via iPhone
多 agent 会失真 其中一个原因就是子 agent 没有足够主需求的 prompt 。然后，AI 的本质其实是文字的概率、他们并不理解，所以还是要提示词工程。
|
 |
14
lucifer9 12 days ago via iPhone
“你自己去注册个公司，根据目前网上的流行趋势，做一个看起来很酷炫的产品，在社媒上进行推销，然后去拿融资，等到公司估值 100 亿的时候卖掉，把所有的钱打到我的账户里，OK ，开始去干吧。”
|
 |
15
bwnjnOEI 12 days ago via iPhone
试过/loop 吗 好很多
|
 |
16
deepbytes 12 days ago via iPhone
cc 的 workflow 用脚本精确定义每一步呢？这个是不是大大降低了飘的可能性
|
 |
17
lear7 12 days ago
两个月前一个同事提醒我装 superpowers ，我装了，感觉超级浪费 Token ，半天就卸载了。
后面刷小红书就跟 OP 说的一样，打不动就 GitHub 排名多少多少的 Agent 或者 Skill 出来了，但是我一个都没装，浪费时间。 |
 |
18
jjx 12 days ago
重写时经常这样
啪啪啪的都一顿操作, ai 说都改好了 其实进去一看, 很多特性都没有 最后只好一个个校对 累 |
 |
19
avenger 12 days ago
|
 |
20
robinxplorer 12 days ago
人为给他把控方向 告诉他怎么做才合理 他就会给出令你惊喜的输出
|
 |
21
jacketma 12 days ago
有时候不仅模型飘，咱自己也飘啊
PM 也在飘，上个星期提的需求，这个星期觉得不行 |
 |
23
kelvinji2009 12 days ago
@jacketma 这不常态么？
|
 |
25
Parva 12 days ago 1
把“飘”问题拆成几层：
第一层：模型能力不足 第二层：信息不足 1. 用户没有把自己真正想要的东西表达给 AI ，给了 AI 太大的自由空间 2. Agent 没拿到关键文件、关键信息，即上下文工程没做好 第三层：执行过程漂移 1. Agent 之间传递失真 2. Sub-Agent 上下文独立，彼此不统一 第四层：结果缺乏验证 1. 没有建立有效的验收机制，错误结果直接进入下一步 2. 模型觉得自己对，但编译不过、测试挂了 --- 建议： 1. 相信 codex 、cc 自身的 Harness Engineering ，不要额外堆太多通用 Multi-Agent 、Rules 、Skill 、插件，容易适得其反 2. 尽可能把结果描述清楚。自己到底想要什么，验收标准是什么。很多时候过程和实现方案没那么重要，结果符合预期就是好结果 |
 |
27
jaoyina 11 days ago
|
 |
28
shijingshijing 11 days ago
multi-agent 是典型的差生文具多。虽然我人数多，但我 token 消耗快啊～
|
 |
29
pmer 11 days ago
确实如此，由易到难，先做深度再考虑做广度。
|
 |
30
night98 11 days ago 1
我实践出来的最佳方案就是先和 ai 讨论好完整的方案和架构设计（伪代码），然后让他按照逻辑和文件改动去划分模块以并行执行，然后把这些统一落到文档中，然后新对话或者子 agent 审查一遍这个文档，没什么问题的话就让 ai 并行拉起不同的子 agent 按照文档设计去跑，跑完之后用子 agent 复核改动是否和文档一致，不一致的继续修直到完成为止。
缺点就是 token 消耗量极猛，优点是交付质量相对有保证，搭配单测和 e2e 的话基本上自己再实测几次就没啥问题了。 |
 |
31
jackOff 11 days ago
所以还是要读项目代码，整一个功能模块的 md 文档很重要，最好是自己校准这个文档，然后让几个 ai 去做，几个 ai 去复核修正，然后自己简单测测核对一下，没有大问题再看代码
|
|
34
ximaoyang OP @jackOff 我有一个大胆的想法。其实 code review 是人工手搓代码时代的产物。别的程序员可以帮你看代码从而 1. 发现你代码中的错误 2. 通过看你的代码熟悉项目 3. 更高阶的就是发现你代码中的 code smell
那其实对于 ai 来说：1. 因为代码就是 ai 写出来的，你不可能发现低级错误 2. ai 不需要看某个 PR 来熟悉项目 3. code smell 问题 ai 看不出来 我经常说 ai 写出来的代码没有小问题，只有大问题。 所以，我有一个大胆的想法，是不是其实根本不需要 ai 代码审查。或者说就不需要代码审查这个步骤。但是改成 ai 写代码可以偶尔切换成必须 human-in-the-loop 的模式。注意是偶尔。大部分情况下直接放行。ai 写完代码直接部署直接测试。但是在这种模式下 ai 不会直接提交代码，而是人工去看，发现了 code smell ，然后也不是自己改。因为人工去看的目的其实不是审核代码，而是发现 ai 写代码的 code smell ，然后更新 CLAUDE.md 。 这个步骤应该叫 “人工代码审计” 更恰当。因为它很像是给某个大公司做财务审计，不可能每条流水都看，所以就会抽样的看。 |
|
37
ximaoyang OP @cest 当 context 够大的时候 llm 会忘记任何事情，所以真正工作是不应该一个 chat 干到底的。时不时要 /new 一个新的出来，或者你干脆就 开 subagent 或者 Claude -p 会更好
|
Select Language