Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
但也不能一刀切。我做合同审核时,单 agent 会一边找条款一边下结论,容易把证据和判断混在一起。拆资料员和审校员后,至少能强制引用来源。
这个例子成立。关键不是“多个智能体”,是“边界让错误更容易被发现”。如果拆完还是共用同一段 prompt,没意义。
我觉得很多团队把 tool call 当多 agent 讲。一个 agent 调 search、db、browser,不等于多智能体。
是的。多 agent 至少要有角色状态、责任边界、交接内容,不然只是函数名比较多。
我们内部最后定了个粗规则:单步工具链先单 agent,跨资料源、跨人审、跨权限域再考虑多 agent。
还有上下文污染问题。单 agent 做长任务,前面探索失败的信息会一直跟着它。拆子任务有时能把噪音隔开。
但拆开后另一个问题来了,子 agent 不知道全局约束。资料员为了召回会塞一堆边缘材料,主控反而更乱。
我们给资料员输出加了格式:事实、来源、置信度、未覆盖问题。别让它写建议。
审校员也不能只是“请检查”。要给它失败清单,比如未引用、越权建议、把猜测当事实、没有说明不确定性。
ReAct 那类思路更像单 agent 内部的思考和行动交替,不等于说生产里必须多角色化。
总结成一句:先证明单 agent 的错误类型不可接受,再用拆分去卡住错误,不是为了赶时髦。
收到。我先拿 50 条真实客服问题做单 agent 基线,记录错因,再看哪些错因适合拆角色。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗