Загрузка видео...
Не удалось загрузить видео
腾讯workbuddy产品负责人汪晟杰： “每一个APP背后都有一个对应的CLI，有了CLI就可以让大模型调；未来腾讯所有的产品背后都会有CLI，传统的软件背后都应该有CLI。 CLI不是目的，CLI是为了让大模型理解你，从而让AI调用的时候不需要APP ” 图形界面（GUI）是给人看的，颜色和按钮是为了帮人理解系统，但 Agent 不需要这些。让 Agent 去等网页加载、识别按钮模拟鼠标，纯属绕远路，命令行（CLI）和结构化数据对它来说直接得多。 如果未来入口变成AI Agent，那就是人与Agent沟通，Agent通过CLI与各种应用和软件沟通
169,962 просмотров • 1 месяц назад •via X (Twitter)
Комментарии: 37
CLI 更像是过渡形态。大模型真正需要的是 schema/IDL 和权限边界，而不是让用户去背命令行参数。很多业务系统没有稳定 CLI，反倒有 API 和事件总线。未来大概率是：人看 GUI，Agent 读 schema，CLI 留给运维和开发者临时救火。说每个 APP 背后都得有 CLI，听着像在把 GUI 时代反着走一遍。
GUI 只是翻译器，而 CLI 才是直接表达意图
有道理 学习了 公号已关注
这种事也只有非技术人讲出来，有感染力！哈哈哈
腾讯手里为数不多的好牌就是 微信cll
按这个逻辑去推导，UI的范式也要改变：UI会变为UAI（User-Agent Interface）；UX会变为UAX（User-Agent Experience）。试想用户不再需要在功能繁杂的仪表盘中找符合自身需求的功能，而是Agent先采访用户（grill-me），问出准确需求后，再一步到位给出跳转入口 Cloudflare的Agent化配置已经有这个趋势了
这下产品经理也得懂点命令行了
本来就应如此 未来的软件两条路径给人用的接口 给 ai用的接口
半年前的共识，现在拿出来说
未来你妈啊，你现在也不能 Computer use 啊，Codex 为什么能？为什么做不到 Codex 这种能力？心里没数么
认知永远落后老外一年，这什么猴年马月的思想了拿出来说，怪不得产品不行
确实，根儿上的思维就不一样
不就是MCP么，被说了两三年了
我需要一个脑机接口
你这个太先进了 马斯克在努力中 🤪
未来 App 要同时提供两套入口：一套给人操作，一套给 Agent 调用。CLI、API 和 MCP 不只是开发工具，也可能成为新的产品分发渠道。
真正的智能手机就是这样的
CLI规则 不就是claude code推广出来的么
这就是AutoCAD一直在做的事
你怎么看？
这是啥时候的采访？这个放在现在是人尽皆知的事情呀
我能说一句这个观点我 4 个月前在内部分享会提到过🤫
这是去年就有的共识了，不然openCLI怎么火起来的。现在还理直气壮的说出来
桌面端 Agent 已经有 Shell，移动端没有。 所以我在 iPhone App 里造了一台：对模型的输入输出而言，它和真 Shell一样——命令、语法、stdout/stderr等全部对齐；对系统而言，它只是 App 明确定义、授权和审计的本地能力。 Agent 能直接通过我做的shell操作手机本地照片、文件和 App 状态
确实，这东西都老掉牙了，还说啥。说不定在过一段时间cli也不需要了，直接ai原生系统呢？或者ai直接就可以原生理解这些东西呢，cli也没有必要做了
智能体干活，最主要就 2 个， 要么是 CLI，要么就是 API。
前端哥点评到位 👍
所以也不需要单独设计什么ai操作系统了，*inux就完全适配
那我的银行App的余额信息各种数据安全呢
拉倒吧，问问国内这些赛博地主同不同意，cli也只给自己家应用调用
Make Cli Great Again, AKA MCGA.
cli 的话客户更加两眼一抹黑，任 ai 摆布
CLI等于让各大APP放弃成为流量平台和入口，谁愿意？
GUI伺候人，CLI伺候AI，人伺候AI，闭环了
为什么是CLI而不是DLL或者其他的什么
cli就是API的另一种说法
为啥不是 api or mcp?
![大家都在卷云端Agent，我却把多Agent做进了桌面端 在技术社区，多Agent系统的文章越来越多，但大多数都围绕框架展开： ➢LangChain ➢AutoGen ➢CrewAI 我这次想讲的不是框架，而是一个更实际的问题： 如果不搭云端基础设施，只靠一个桌面应用，能不能从零构建一个“活的”多 Agent 协作系统？ 答案是：可以 --- 而且它不是Demo 这套系统，长在一个真实的桌面Web3应用里，已经集成了： -EVM / Solana 双链监控 -SWAP 聚合交易 -链上新币追踪 -交易仪表盘 -AI 深度解读 多Agent不是从PPT里设计出来的，而是在生产环境中自然演化出来的。 --- 在讨论多Agent技术实现之前，我先回答一个方向性问题： 为什么我最后选的是桌面端，而不是更主流的云端部署，或者更轻的浏览器插件方案？ 这个选择的本质，不是“谁更先进”，而是三条技术路径之间的权衡。 --- 云端部署，是当下最主流的多Agent实现方式。 它的优势很明显： 可以随时为Agent团队加GPU 模型升级不需要用户干预 服务端可以维护全局共享记忆 但代价同样明显： 用户数据必须经过服务器中转 链上交易往往要对服务器开放私钥访问权限 而且会持续产生部署和维护成本 --- 浏览器插件，是另一条轻量路线。 它可以直接注入页面，读取DOM，模拟用户操作，对单一自动化任务非常高效。 但问题也很直接： >它运行在浏览器沙箱里 >缺少持久化存储能力 >缺少长时间运行的后台线程 >很难支撑复杂的记忆系统 >也很难支撑Agent与Agent之间的异步互动 --- 桌面应用则处在一个独特的位置。 它拥有完整的系统资源访问权限： ➢可以自启动后台线程 ➢可以读写本地文件系统 ➢可以建立持久化数据库连接 这些能力，恰恰是多Agent系统真正需要的底层设施 代价当然也有： 它依赖本地算力，模型推理通常仍要调用云端 API 它需要完整 Python 环境 更新和分发也比网页应用更复杂。 --- 所以，选择桌面端构建多Agent，本质上是在用分布式能力，换取数据隐私和调度效率。 这不是绝对优势，而是场景决定的选择。 对加密货币交易、链上分析、监控这类系统来说，数据隐私要求远高于常规应用： >钱包地址 >交易历史 >持仓数据 这些信息落在云服务器上，本身就是风险面。 --- 更重要的是调度效率 在单体桌面应用里，主Agent调度子Agent执行任务，不需要走HTTP / RPC这类网络协议，而是可以直接进程内调用。 这意味着： →网络开销被彻底消除 →调用延迟从毫秒级压到微秒级 对高频分析、链上监控、交易辅助这种场景来说，这种差异会直接影响系统的时效性。 --- 多Agent系统的第一个核心挑战，其实不是“怎么让它们聊天”，而是“怎么把它们隔离开” 主Agent、合约分析Agent、安全审计Agent，再加上用户，如果聊天记录和记忆混在一起，身份就会混淆。 而一旦混淆，信息丢失和错误推理的代价，随时会发生。 --- 我的做法是： 代码模板统一，运行数据隔离 所有子Agent共用同一套 ` 引擎，但通过动态表名，实现物理级的数据隔离： `table_name = f"chat_history_{self.agent_id}"` 然后自动创建对应表。 也就是说： trader Agent会生成 `chat_history_trader` 审计 Agent 会生成自己的 `chat_history_xxx` 主 Agent 也有自己的独立聊天表 这不是逻辑隔离，而是数据库层面的物理隔离。 --- 反思笔记也是同样的设计。 每个子 Agent 都会记录自己的反思键： `reflection_key = f"auto_reflection_{self.agent_id}"` `self.api._agent_remember("master_insight", reflection_key, summary)` 这样每个Agent只积累自己的长期反思， 不会污染其他Agent的记忆。 这套方案最精髓的地方在于： 一次设计，终身复用。 --- 后面再新增第三个、第四个Agent，不需要改任何核心代码。 只需要复制目录结构，补上配置文件。 模板引擎就会自动为它生成： →独立数据库表 →独立反思键 →独立聊天存储区 这让我越来越相信一件事： 好的架构，不一定更复杂， 但一定更容易复用。 --- 接下来是调度问题。 在分布式系统里，主Agent调子Agent，通常要依赖： -HTTP / RPC 通信 -服务发现 -负载均衡 但在单体桌面应用里，我把这件事简化成了一个直接函数调用： `sub = self.sub_agents[agent_id]` `result = sub.process(task, save_history=False)` 这就是“命令而非请求”。 --- 这种“传话式调度”有两个好处： 第一，延迟从毫秒级降到微秒级，所有数据都留在本地流转 第二，主 Agent 不需要知道子 Agent 的内部实现细节，只需要知道： “它可以处理什么类型的任务” 这其实就是清晰的职责边界。 --- 为了让主Agent真正会“派活”，我把所有子Agent的能力清单，动态注入进主Agent的系统提示词。 例如： 合约分析 Agent：可用工具 `get_contract_market_data`、`run_contract_risk_check` 安全审计 Agent：可用工具 `check_token_security`、`check_token_audit_binance` 这样主Agent接到用户指令后，就能自动判断任务类型，并选择合适的子Agent执行。 --- 权限控制，是整个多Agent系统里最核心的安全问题之一。 主Agent持有26个Web3专属工具，覆盖： SWAP 报价 链上分析 安全检测 数据查询 但每个子Agent只应该使用自己那一小部分工具。 所以第一层，我在代码层做了严格白名单过滤： `return [t for t in all_tools if t["function"]["name"] in self.allowed_tools]` --- 但只有代码过滤还不够。 因为大模型会产生“幻觉”，它可能尝试调用未授权工具。 所以第二层，我在系统提示词末尾，直接写入“工具使用铁律”： 你只拥有以下这些工具，绝对不能越界。 如果任务需要其他工具，必须明确告诉老板你没有权限。 代码层负责“不能看到” 提示词层负责“不会越界” 这是我在权限隔离上做的双层防护。 --- 还有一个我自己很喜欢，但最不显眼的设计： 我给整个Agent 团队，单独做了一个茶水间 市面上多数多Agent系统，只做“用户 -> Agent”的交互。 Agent 之间互不交流。 但我单独设计了一个 `agent_interactions` 空间，让 Agent 和 Agent 之间也能异步互动。 --- 它的触发机制甚至很简单： `selected_id = random.choice(list(api.sub_agents.keys()))` `selected_sub = api.sub_agents[selected_id]` 每次触发时，引擎随机选人，动态生成一轮对话，再写回数据库，前端实时渲染。 我还额外加了后台检查线程和防无限循环机制： 每隔 2-3 分钟检查最后一条消息 如果最近 3 条都是自动回复，就自动暂停 避免它们半夜自己聊到停不下来。 --- 这个“茶水间”的价值不在于直接创造业务收益，而在于一种潜移默化的系统人格塑造。 它不强调自己的存在， 却在悄悄维持 Agent团队的凝聚力、性格关系和健康状态。 你几乎感觉不到它， 但系统会因为它，变得更像一个“活着的团队”。 --- 在记忆层设计上，我最后没有引入向量数据库，而是继续深度定制 SQLite。 不是因为技术保守，而是因为工程决策必须在约束条件下做权衡。 对桌面应用来说，多一个依赖，就多一个故障点、多一个安全风险面、多一个打包负担。 结果是： >几张SQLite表 >动态表名 >结构化JSON字段 就支撑起了3个乃至更多Agent的独立记忆系统。 --- 这套记忆系统现在已经形成了一条完整链路： 短期对话记忆（20条） -> 长期反思笔记（6小时一次） -> 结构化 JSON 记录 而我还在继续推进8个方向： ➤上下文延续 ➤记忆结构化 ➤记忆驱动行为 ➤心理学三类长期记忆 ➤团队协作记忆 ➤动态进化记忆 ➤知识图谱记忆 ➤记忆压缩与高效检索 我的目标，不是让Agent记住你说过什么 而是让它从记住你说过什么的工具，慢慢进化成能理解你、预测你、协同你的长期伙伴 GitHub: 作者：Powerpei（萧楠）](https://image.24vids.com/tw-2054369610401747322/amplify_video_thumb/2054367623903928320/img/DSgcKqTZ06uH70-i.jpg)