最近在做一个多 Agent 协作的 AI 开源项目，想和大家聊聊这个方向的未来发展方向，迸发一下灵感
- 内容介绍
- 文章标签
- 相关推荐
最近一直在折腾一个东西，其实也不算新，就是多 Agent 协作那一套
不过我这边是做的是多CLI协作，支持基本上所有的CLI，也算是不重复造轮子了，各个大厂的cli拿来都可以用
之前也发了项目帖子宣传了一下，创建蜂群Agent Team，24小时运行你的AI公司的编程应用更新到0.1.9版本，佬友们，快快更新
大家使用感受好像都还不错？
但是我感觉还是不够完美，所以这个帖子就是讨论一下多AGENT未来的趋势
简单说下在干嘛：
不是一个 AI，而是一堆 AI，一起干活，有点像你带一个团队那种感觉。能分工，有上下游，还能一直跑，不是那种问一句回一句的。
现在大概做的东西是：
- 多个 Agent 可以组一起干活
- 能接各种 CLI / 工具 / 别的 Agent（不重复造轮子）
- 可以自己搭工作流，导入导出模版
- 支持长时间跑，不是一次性的
有几个点我自己觉得还挺有意思的（也可能是自嗨）：
- 可以看到每个 Agent 在干啥，是命令行级别
- 可以直接插手某个 Agent，而不是全黑盒
- 整体更像一个系统，而不是聊天工具
我有个更离谱一点的想法：
能不能搞出一个“AI 自主运行的公司”这种东西
比如：
一个类似 CEO 的 Agent
负责拆任务
然后自己去生成、管理别的 Agent
再根据情况自己调结构、调分工
理想情况是可以一直跑，他自己完全知道自己在干嘛，比如一个月不管它那种
听起来挺扯的，但现在感觉也不是完全没戏
不过做着做着就开始怀疑人生了，有几个问题一直想不明白，想听听大家怎么想：
1. 多 Agent 这东西到底有没有必要？
说实话很多时候
一个 Agent + 工具调用 其实已经够用了
那我现在搞这么一套：
自我感觉是更强了，但是token消耗也变大了，复杂度也爆炸
2. 到底要不要做那么多“可视化”和“可干预”？
我现在是可以看到每个 Agent 在干嘛的
但问题是：
用户真的会看吗？
还是说其实大家只想要一个结果，过程根本不关心
3. 长时间运行这种东西到底是不是刚需？
比如自动做内容、自动运营这种
听起来很爽
但现实可能是：
- 不稳定
- 成本高
- 一出错就全崩
这东西到底是未来
还是伪命题
4. Agent 应该做成通用的还是分得很细？
现在有点纠结：
一种是啥都能干的 Agent
一种是职责很死的那种
感觉两边都有坑
5. 有没有人已经踩过大坑的…
我现在已经踩到一些了，比如：
- 上下文越来越大
- Agent 之间互相说不清楚
- 成本有点控制不住
- 时间长了，会忘记自己是谁
有点头大
整体感觉就是：
这方向好像是对的，但又感觉大家都在乱试，还没一个比较“稳”的形态
有点像当年刚开始搞微服务那会儿
就随便发个帖，想听点真实一点的对未来多AGENT的看法
不管是觉得这东西有戏的
还是觉得纯属自嗨的
都可以说说
我现在也在反复怀疑这玩意到底值不值得继续往下搞
网友解答：--【壹】--：
转换成古法编程。
一个人单独做产品全流程，与一个团体做产品全流程。
一个人自己要做啥知道，但不是啥都会的。而团队一半的时间都是在反复沟通上，但是各有所长。
多agent目前在上下文只有200k的情况应该是最优解的。如果说未来上下文在1M的情况下并且全程注意力没有衰退的很严重，我觉得单是比较合理的。
--【贰】--：
已经做了一个，你的这些是可以实现的，可以看看视频。https://www.bilibili.com/video/BV1k7PczeELY/?spm_id_from=333.1387.0.0&vd_source=99a6a5e6529f563261503f851a93c005
--【叁】--：
佬友你说的这个好像和我最近在用的这个项目很像
GitHub - paperclipai/paperclip: Open-source orchestration for zero-human companies
Open-source orchestration for zero-human companies
--【肆】--：
agent我认为它的复杂度和可控制度是比一般的workflow上了一个层次的，因为AI介入了决策，我觉得目前有两种风风格的agent：
- 命令风格：比如codex这种，我让你建立这个项目，你就完整地计划，写代码，写测试，修bug。但本质还是我在控制大决策，没有AI团队在替代人的作用，这更像是一个workflow+loop的工作形式，只不过loop和workflow由AI定制，它自己决定什么时候应该进入循环loop去解决问题。
- 替代风格：比如佬说的自动做内容的agent，它自己爬取新闻，筛选自认为好的新闻，总结摘要，生成文章这些，哪里做的不好了，自己再决定是否返工。人在里面几乎不参与决策，即使有所谓可视化，也几乎不可控。
前者也就是佬说的什么都能干的agent，非定制化的一种工具。
后者就是职责很死的，一个定制的流程。但是其内容是自由的。
这就是我分类的两种agent。不过前者来说，什么都能干其实就太夸张了，但是确实是比较多范围可以干的事情，不是窄化的助手。
需要吗？
事实上
我认为多数工作完全不需要agent，不需要AI参与决策，你只需要写一个workflow。比如整理一堆试题，分类，那么就写一个管道式的娱乐，处理OCR-调用AI-娱乐整理清洗-输出。这里面，根本不需要AI去记住啊这是第几步了，我应该调用什么工具啊，不需要的，它的目的很明确。
只有一些评价的，无法预测的东西，它目的不明确，我们才引入agent。
比如说做ppt，这是无法预测的吧，你无法说这个PPT能通过一个逻辑固定的方式去做，即使做了也不一定做好。它需要AI去返工，去评价和决策。所以引入了agent：第一步收集资料，有一个agent说你这收集的不好，再次来收集，一直到他们通过为止。第二步写文档，又有另外一个agent，评价你这文档如何如何，调用一些标准来完善。第三步写PPT，有一个agent，写完后视觉评价你这PPT如何如何，然后又改。
workflow解决自动化问题，agent解决自治的问题。
评价和决策的重要性，才是是否使用agent的标准。
是未来吗？
娱乐生产
我还是回到前面的两个分类，命令风格的 Agent 将成为下一代操作系统。 它通过推理和决策，把人类从繁琐的软件 UI 中解放出来。我们不再学习如何使用工具，而是学习如何下达决策。
这是生产力的提高，但是我们还是在生产之中。我们还是决定着任务质量，代码项目的褒贬。
脱离生产
替代风格的 Agent 将成为下一代生产关系。你不需要像前者一样，我们来写一个大纲，我们来写一个情节设定，角色设定，你直接说你要什么需求吧，我要一本小说，这本小说应该怎么样怎么样才算好，那么很快我们不在乎过程怎么样，我不参与小说的内容，情节规划等等，我只做一件事
定义什么样的结果是好？
然后agent启动自动写小说，完了以后给我一本小说。
人类脱离了生产了。
当然这一步如果真的实现了，就有盛世的感觉了。目前AI本身能力有边界，这种结果能不能达到水平，在这里完全取决于模型本身，和人没有关系。
--【伍】--：
是的，不过我主要是惊艳在它可以自主生成agent员工的概念
--【陆】--：
我现在的经验就是，你本人必须得是那个指挥中心，不能纯黑箱。就像做生意，老板不能一窍不通也不能做甩手掌柜一样的 所以效率快，但是人还是非常累
--【柒】--：
之前刷到过佬的b站视频, 但是没有去实际体验过项目, 就姑妄言之.
首先是 1. 多 Agent 这东西到底有没有必要？
如果是coding的话subagent能够保持上下文干净还是有一些必要, 像gsd的核心理念, 每个subagent具有干净的200k上下文来进行具体执行. 从attention的公式和实际体验来说, 上下文干净且在一定长度范围内的 LLM 解决问题的能力更好. 当然必须的context还是要移交.
然后就是区分领域专职agent, 比如 前端/后端 agent, 能够专注于单一领域知识, 我自己在实践中是能得到更好的效果的. 但是像佬视频里那种 多员工 我感觉作用不是很大.
另外agent数量我感觉在3-5个就已经是极限了, 像omo原版那种过多的agent我反而觉得太重, 一方面token消耗太大, 一方面效果其实也不见得能好.
然后 2. 到底要不要做那么多“可视化”和“可干预”？
可视化见仁见智吧, 总有一部分人需要监控. 可干预感觉还是没有什么问题, 就像gpt5.4可以随时改变思考过程(
3. 长时间运行这种东西到底是不是刚需？
目前来说, 我的观点是一定的长时间运行是有需求的, 但是不是那种 完全自动化运行的. 像一些插件的hook 停止, 能够减少人工干预, 进行一些长程开发. 但是考虑到上下文腐化和各个agent之间的交流和信息移交, 如果持续运行超过1h我可能就得害怕了
4. Agent 应该做成通用的还是分得很细？
感觉领域专用agent好点吧, 比如 agent 同时负责 通用任务和coding的话, 我的实际体验是不太好的.
5. 有没有人已经踩过大坑的…
关于 1. 2. 小点可以看一下Trellis吧, 虽然我也是最近才用这个插件
在现在比较统一的持久化记忆文件里面我感觉Trellis做的算比较好, 同时比较’轻’的, 阶段化也比较清晰
第 4. 小点 现在普遍也是用hook来在subagent启动的时候强调自我认知, 而且又要谈到 subagent的任务分配了(
对每个subagent任务给的太重又会导致上下文腐烂, 尽量分阶段, 每次移交一个比较小的phase(gsd的做法) 可能比较好?
一些个人不太成熟的见解, 希望能帮助到佬友
--【捌】--：
OpenClaw 多Agent协作 ？
--【玖】--：
多agent协作带来的基本只是增熵
--【拾】--：
这个项目我使用过的，说一下感受吧，第一底层的agent还是不够强大，完成编码这种复杂的任务还是不大行，协作能力没有看出来，比较新颖的是类似定时任务的这种，第二就是，有连接错误，经常会出现连接不上的问题，第三就是，我感觉还是比较复杂，不能实现言出法随的感觉
--【拾壹】--：
很像最近看到的这个项目
GitHub - xvirobotics/metabot: Infrastructure for building a supervised,...
Infrastructure for building a supervised, self-improving agent organization. Run Claude Code from Feishu & Telegram with shared memory, agent factory, task scheduling, and an agent communication bus.
类似的应该挺多了，不过都很难评估到底能带来多少效益吧
--【拾贰】--：
佬的我用过，体感很复杂，不管是大的还是小的需求，都做得很久。
--【拾叁】--：
得落地啊.我觉得你先考虑的应该是.
实际应用的场景是什么? 哪怕举出一个例子都行.
具体到每个agent负责什么的.他们要做什么任务.他们为什么要分工.谁来决定
技术上都不是难题..就是别被概念玩坏了..
--【拾肆】--：
不止openclaw，你可以去看看具体介绍
--【拾伍】--：
你现在有没有可以用的产品了，我想来试试，我最近和你的想法差不多，我是想的一个AI先给我拆分任务，然后分发给调度器，调度器再给接上来的AI工具去开发，有点像AI编排工具，这个接上来的工具可以是本地，也可以是容器里面的或者openclaw这样的，分发完任务就各司其职干活，晚上一个任务就通知调度器，调度器收到结果计算整体进度
--【拾陆】--：
好像现在主流模型都支持1M了吧，长上下文应该是未来的趋势
--【拾柒】--：
我也正在做这套东西,但是我的方向在一个大任务拆解出一堆任务,循环执行,多Agent我还是觉得有必要的,每个Agent必须是干净的上下文,只有主Agent 需要了解项目现状,框架等前提知识,这就需要主Agent能力够强,
2.可视化我觉得方向在每个agent 分配任务的prompt内容应该是可知的,至于anget正在干嘛,我觉得是细节部分,没必要去看
3.刚需,你看我现在方向就是这个,当然我是code方向,如果说其他方向,我感觉你需要一个task进度,定时运行
4.Agent我觉得要归类分则
--【拾捌】--：
多agent只适合任务严格划定的东西 就是一个队长和若干小干事 小干事帮忙探索和汇总上下文 或者干并行翻译的任务 就是那种可支持高度并行的任务或者上下文/效果比很低的活 例如进入了某个流程 或者探索代码结构告诉agent应该关注什么的 没必要读取所有文件的时候 才有用 不然我觉得还是一个agent干比较合适
--【拾玖】--：
你想的别人都实践过了，但是那种多角色的 agent 协作实际上会增加幻觉率，也就是说会降低总体任务的成功率，至少目前来看还是要人来约束。
最近一直在折腾一个东西，其实也不算新，就是多 Agent 协作那一套
不过我这边是做的是多CLI协作，支持基本上所有的CLI，也算是不重复造轮子了，各个大厂的cli拿来都可以用
之前也发了项目帖子宣传了一下，创建蜂群Agent Team，24小时运行你的AI公司的编程应用更新到0.1.9版本，佬友们，快快更新
大家使用感受好像都还不错？
但是我感觉还是不够完美，所以这个帖子就是讨论一下多AGENT未来的趋势
简单说下在干嘛：
不是一个 AI，而是一堆 AI，一起干活，有点像你带一个团队那种感觉。能分工，有上下游，还能一直跑，不是那种问一句回一句的。
现在大概做的东西是：
- 多个 Agent 可以组一起干活
- 能接各种 CLI / 工具 / 别的 Agent（不重复造轮子）
- 可以自己搭工作流，导入导出模版
- 支持长时间跑，不是一次性的
有几个点我自己觉得还挺有意思的（也可能是自嗨）：
- 可以看到每个 Agent 在干啥，是命令行级别
- 可以直接插手某个 Agent，而不是全黑盒
- 整体更像一个系统，而不是聊天工具
我有个更离谱一点的想法：
能不能搞出一个“AI 自主运行的公司”这种东西
比如：
一个类似 CEO 的 Agent
负责拆任务
然后自己去生成、管理别的 Agent
再根据情况自己调结构、调分工
理想情况是可以一直跑，他自己完全知道自己在干嘛，比如一个月不管它那种
听起来挺扯的，但现在感觉也不是完全没戏
不过做着做着就开始怀疑人生了，有几个问题一直想不明白，想听听大家怎么想：
1. 多 Agent 这东西到底有没有必要？
说实话很多时候
一个 Agent + 工具调用 其实已经够用了
那我现在搞这么一套：
自我感觉是更强了，但是token消耗也变大了，复杂度也爆炸
2. 到底要不要做那么多“可视化”和“可干预”？
我现在是可以看到每个 Agent 在干嘛的
但问题是：
用户真的会看吗？
还是说其实大家只想要一个结果，过程根本不关心
3. 长时间运行这种东西到底是不是刚需？
比如自动做内容、自动运营这种
听起来很爽
但现实可能是：
- 不稳定
- 成本高
- 一出错就全崩
这东西到底是未来
还是伪命题
4. Agent 应该做成通用的还是分得很细？
现在有点纠结：
一种是啥都能干的 Agent
一种是职责很死的那种
感觉两边都有坑
5. 有没有人已经踩过大坑的…
我现在已经踩到一些了，比如：
- 上下文越来越大
- Agent 之间互相说不清楚
- 成本有点控制不住
- 时间长了，会忘记自己是谁
有点头大
整体感觉就是：
这方向好像是对的，但又感觉大家都在乱试，还没一个比较“稳”的形态
有点像当年刚开始搞微服务那会儿
就随便发个帖，想听点真实一点的对未来多AGENT的看法
不管是觉得这东西有戏的
还是觉得纯属自嗨的
都可以说说
我现在也在反复怀疑这玩意到底值不值得继续往下搞
网友解答：--【壹】--：
转换成古法编程。
一个人单独做产品全流程，与一个团体做产品全流程。
一个人自己要做啥知道，但不是啥都会的。而团队一半的时间都是在反复沟通上，但是各有所长。
多agent目前在上下文只有200k的情况应该是最优解的。如果说未来上下文在1M的情况下并且全程注意力没有衰退的很严重，我觉得单是比较合理的。
--【贰】--：
已经做了一个，你的这些是可以实现的，可以看看视频。https://www.bilibili.com/video/BV1k7PczeELY/?spm_id_from=333.1387.0.0&vd_source=99a6a5e6529f563261503f851a93c005
--【叁】--：
佬友你说的这个好像和我最近在用的这个项目很像
GitHub - paperclipai/paperclip: Open-source orchestration for zero-human companies
Open-source orchestration for zero-human companies
--【肆】--：
agent我认为它的复杂度和可控制度是比一般的workflow上了一个层次的，因为AI介入了决策，我觉得目前有两种风风格的agent：
- 命令风格：比如codex这种，我让你建立这个项目，你就完整地计划，写代码，写测试，修bug。但本质还是我在控制大决策，没有AI团队在替代人的作用，这更像是一个workflow+loop的工作形式，只不过loop和workflow由AI定制，它自己决定什么时候应该进入循环loop去解决问题。
- 替代风格：比如佬说的自动做内容的agent，它自己爬取新闻，筛选自认为好的新闻，总结摘要，生成文章这些，哪里做的不好了，自己再决定是否返工。人在里面几乎不参与决策，即使有所谓可视化，也几乎不可控。
前者也就是佬说的什么都能干的agent，非定制化的一种工具。
后者就是职责很死的，一个定制的流程。但是其内容是自由的。
这就是我分类的两种agent。不过前者来说，什么都能干其实就太夸张了，但是确实是比较多范围可以干的事情，不是窄化的助手。
需要吗？
事实上
我认为多数工作完全不需要agent，不需要AI参与决策，你只需要写一个workflow。比如整理一堆试题，分类，那么就写一个管道式的娱乐，处理OCR-调用AI-娱乐整理清洗-输出。这里面，根本不需要AI去记住啊这是第几步了，我应该调用什么工具啊，不需要的，它的目的很明确。
只有一些评价的，无法预测的东西，它目的不明确，我们才引入agent。
比如说做ppt，这是无法预测的吧，你无法说这个PPT能通过一个逻辑固定的方式去做，即使做了也不一定做好。它需要AI去返工，去评价和决策。所以引入了agent：第一步收集资料，有一个agent说你这收集的不好，再次来收集，一直到他们通过为止。第二步写文档，又有另外一个agent，评价你这文档如何如何，调用一些标准来完善。第三步写PPT，有一个agent，写完后视觉评价你这PPT如何如何，然后又改。
workflow解决自动化问题，agent解决自治的问题。
评价和决策的重要性，才是是否使用agent的标准。
是未来吗？
娱乐生产
我还是回到前面的两个分类，命令风格的 Agent 将成为下一代操作系统。 它通过推理和决策，把人类从繁琐的软件 UI 中解放出来。我们不再学习如何使用工具，而是学习如何下达决策。
这是生产力的提高，但是我们还是在生产之中。我们还是决定着任务质量，代码项目的褒贬。
脱离生产
替代风格的 Agent 将成为下一代生产关系。你不需要像前者一样，我们来写一个大纲，我们来写一个情节设定，角色设定，你直接说你要什么需求吧，我要一本小说，这本小说应该怎么样怎么样才算好，那么很快我们不在乎过程怎么样，我不参与小说的内容，情节规划等等，我只做一件事
定义什么样的结果是好？
然后agent启动自动写小说，完了以后给我一本小说。
人类脱离了生产了。
当然这一步如果真的实现了，就有盛世的感觉了。目前AI本身能力有边界，这种结果能不能达到水平，在这里完全取决于模型本身，和人没有关系。
--【伍】--：
是的，不过我主要是惊艳在它可以自主生成agent员工的概念
--【陆】--：
我现在的经验就是，你本人必须得是那个指挥中心，不能纯黑箱。就像做生意，老板不能一窍不通也不能做甩手掌柜一样的 所以效率快，但是人还是非常累
--【柒】--：
之前刷到过佬的b站视频, 但是没有去实际体验过项目, 就姑妄言之.
首先是 1. 多 Agent 这东西到底有没有必要？
如果是coding的话subagent能够保持上下文干净还是有一些必要, 像gsd的核心理念, 每个subagent具有干净的200k上下文来进行具体执行. 从attention的公式和实际体验来说, 上下文干净且在一定长度范围内的 LLM 解决问题的能力更好. 当然必须的context还是要移交.
然后就是区分领域专职agent, 比如 前端/后端 agent, 能够专注于单一领域知识, 我自己在实践中是能得到更好的效果的. 但是像佬视频里那种 多员工 我感觉作用不是很大.
另外agent数量我感觉在3-5个就已经是极限了, 像omo原版那种过多的agent我反而觉得太重, 一方面token消耗太大, 一方面效果其实也不见得能好.
然后 2. 到底要不要做那么多“可视化”和“可干预”？
可视化见仁见智吧, 总有一部分人需要监控. 可干预感觉还是没有什么问题, 就像gpt5.4可以随时改变思考过程(
3. 长时间运行这种东西到底是不是刚需？
目前来说, 我的观点是一定的长时间运行是有需求的, 但是不是那种 完全自动化运行的. 像一些插件的hook 停止, 能够减少人工干预, 进行一些长程开发. 但是考虑到上下文腐化和各个agent之间的交流和信息移交, 如果持续运行超过1h我可能就得害怕了
4. Agent 应该做成通用的还是分得很细？
感觉领域专用agent好点吧, 比如 agent 同时负责 通用任务和coding的话, 我的实际体验是不太好的.
5. 有没有人已经踩过大坑的…
关于 1. 2. 小点可以看一下Trellis吧, 虽然我也是最近才用这个插件
在现在比较统一的持久化记忆文件里面我感觉Trellis做的算比较好, 同时比较’轻’的, 阶段化也比较清晰
第 4. 小点 现在普遍也是用hook来在subagent启动的时候强调自我认知, 而且又要谈到 subagent的任务分配了(
对每个subagent任务给的太重又会导致上下文腐烂, 尽量分阶段, 每次移交一个比较小的phase(gsd的做法) 可能比较好?
一些个人不太成熟的见解, 希望能帮助到佬友
--【捌】--：
OpenClaw 多Agent协作 ？
--【玖】--：
多agent协作带来的基本只是增熵
--【拾】--：
这个项目我使用过的，说一下感受吧，第一底层的agent还是不够强大，完成编码这种复杂的任务还是不大行，协作能力没有看出来，比较新颖的是类似定时任务的这种，第二就是，有连接错误，经常会出现连接不上的问题，第三就是，我感觉还是比较复杂，不能实现言出法随的感觉
--【拾壹】--：
很像最近看到的这个项目
GitHub - xvirobotics/metabot: Infrastructure for building a supervised,...
Infrastructure for building a supervised, self-improving agent organization. Run Claude Code from Feishu & Telegram with shared memory, agent factory, task scheduling, and an agent communication bus.
类似的应该挺多了，不过都很难评估到底能带来多少效益吧
--【拾贰】--：
佬的我用过，体感很复杂，不管是大的还是小的需求，都做得很久。
--【拾叁】--：
得落地啊.我觉得你先考虑的应该是.
实际应用的场景是什么? 哪怕举出一个例子都行.
具体到每个agent负责什么的.他们要做什么任务.他们为什么要分工.谁来决定
技术上都不是难题..就是别被概念玩坏了..
--【拾肆】--：
不止openclaw，你可以去看看具体介绍
--【拾伍】--：
你现在有没有可以用的产品了，我想来试试，我最近和你的想法差不多，我是想的一个AI先给我拆分任务，然后分发给调度器，调度器再给接上来的AI工具去开发，有点像AI编排工具，这个接上来的工具可以是本地，也可以是容器里面的或者openclaw这样的，分发完任务就各司其职干活，晚上一个任务就通知调度器，调度器收到结果计算整体进度
--【拾陆】--：
好像现在主流模型都支持1M了吧，长上下文应该是未来的趋势
--【拾柒】--：
我也正在做这套东西,但是我的方向在一个大任务拆解出一堆任务,循环执行,多Agent我还是觉得有必要的,每个Agent必须是干净的上下文,只有主Agent 需要了解项目现状,框架等前提知识,这就需要主Agent能力够强,
2.可视化我觉得方向在每个agent 分配任务的prompt内容应该是可知的,至于anget正在干嘛,我觉得是细节部分,没必要去看
3.刚需,你看我现在方向就是这个,当然我是code方向,如果说其他方向,我感觉你需要一个task进度,定时运行
4.Agent我觉得要归类分则
--【拾捌】--：
多agent只适合任务严格划定的东西 就是一个队长和若干小干事 小干事帮忙探索和汇总上下文 或者干并行翻译的任务 就是那种可支持高度并行的任务或者上下文/效果比很低的活 例如进入了某个流程 或者探索代码结构告诉agent应该关注什么的 没必要读取所有文件的时候 才有用 不然我觉得还是一个agent干比较合适
--【拾玖】--：
你想的别人都实践过了，但是那种多角色的 agent 协作实际上会增加幻觉率，也就是说会降低总体任务的成功率，至少目前来看还是要人来约束。