wumingshi 发布的最佳帖子

@watsonlll 难道说是某少女乐队吗？一直在不同的地方看到梗但是没开始看（

@rikka 我也想被一堆dom私信，要留什么样的评论才有这效果🥵🥵🥵

https://top81.ws/show.php?f=1&t=2102204&m=18463118
有点感动，很多时候这种分享很快就失效了

看来技术要想持续传承下去本身也很困难（

作者：niconiconi
链接：https://www.zhihu.com/question/607622786/answer/34064346132
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
十几年前英文互联网上有一篇很火的文章《Institutional memory and reverse smuggling》，讲述了技术是如何失传的。我在这里将它翻译出来，可以为其他答案提供支持，也为读者提供些参考。

制度性记忆与反向泄密
制度性记忆有两种形式：人与文档。人记得事物如何工作，以及为什么能工作。有时候他们会将其写下来，将信息存储于某处。制度性失忆的原理与其类似：人离开了，文档丢失、腐烂或者仅仅被遗忘了（正如这里所发生的）。
我曾在某大型石油化工企业工作了几十年。在 1980 年代初，我们设计了并建造了一座化工厂，以便将一种烃类玩意儿精炼为另外一种烃类玩意儿。在这之后的 30 年，这座化工厂的制度性记忆消退了，只留下了黯淡的回忆。哦，工厂还在运作，而且还在为企业赚钱。日常维护照常进行，当地的技工也依然技艺精湛，熟悉控制、阀门、安全和其他事宜。
但是公司已经忘记它实际如何工作了。
几件巧合造成了这样的后果：
• 1980 到 1990 年代，石油行业下行，公司暂时不招聘新人了。到了 1990 年代末，我们的团队由 55 岁以上与 35 岁以下的人组成，青黄不接。
• 我们的设计逐渐过渡为全计算机化。
• 公司进行过一系列的团队重组，我们的办公室搬迁数次。
• 几年之后，有公司收购了我们。我们彻底被溶解进了一家更大的石油化工企业，明显冲击了我们的制度与人员。
制度性考古
2000 年代初，我和许多同事退休了。
2000 年代末，公司想起了这座工厂的存在，并打算做点什么。说具体些，就是消除一个单元的瓶颈以提升产量，并针对增加一组新单元进行可行性论证。
现在他们有了问题。它起初是如何建造的？为什么要建设成这样？它是怎么工作的？
制度性记忆变得愈发模糊。陌生的机器依旧在哼鸣着，吐出一批又一批聚合物。公司知道如何维护它，却已经不确定建设它时究竟使用了什么神秘的魔法。事实上，甚至没人知道该从哪里入手调查。
挖掘文档的责任落在了当初的新人手上，现在他们已经是年长的资深员工了。整个东西与其说是制度性记忆，更像是制度性考古。没人知道这座工厂存有什么文件，以及如果有的话能在哪里找到，以及它以什么样的形式存在。它是由一家已被合并的公司中一个已不存在的团队在已被关闭的办公室里用已淘汰的前数字化方法所设计的。
第一步是调查工厂的名字。人们发现大多数工程师叫的那个名字只是按照其所在地点所起的俗名，工厂还有另一个正式名称——甚至多个。内部设计时有一个工程名，而实际建造时又有一个合资公司名。
1998 年进行档案整理时，分配过一个 ID。2001 年在档案数字化时，又分配了一个 ID。顺便一提，我们不完全清楚应该以哪个系统为准。同时还有一些档案在其他系统的管理之下。
很不走运，1998 年的 ID 指向了一个早在 1998 年前就已经不存在的“图书馆”，这或许正是 2001 年 ID 之下的文档除了最近的例行维护报告之外没有其他东西的原因。当时，我天真的希望数字化可以一劳永逸解决我们的问题。我的经理当时正读着有关于此的一本厚厚的书，我好奇拿过来看。当时看起来似乎很有说服力。
不过，查阅电话与电子邮件线索的老办法起了点作用。旧的研发部门依旧大致保存了，而他们的实体图书馆也存在着。有人成功找到了关于工厂的聚合物工艺，以及为了在研发部门图书馆存档而专门复印的工程文档。巨大的纸质蓝图、工程图以及编辑成册的数据，都在尘封的文件柜中。颇具讽刺意味，这些纸质文档上的 ID 光荣地向我们宣告着：在过去的某个时间点，一家数字化大厂已经已经将它们全部录入。鬼知道那份存档去哪里了。
解读档案
拼凑出一些文档后，工程师们开始寻找去除瓶颈的切入点。遗憾的是，这些文档仿佛是用甲骨文编写的，而且只有一部分。工作只得缓慢地推进。经理半开玩笑的说，工科院校应该开设工程考古学课程。将一堆 30 年前的档案发给学生，然后让学生研究出其工作原理。我很喜欢这个点子。如果开这门课，甚至可以让学生们读读旧的工程教科书，正如修理古董电子管设备的收藏家们所做的那样。
有一些方法和记号我们仍然熟悉，但另一些已经过时多年。即使标准没有正式修改，“哪些东西应该明确记录，哪些东西可以默认假定”的工程文化惯例也已经变化，这使解读十分困难。假如能有一本大开本图鉴总览就好了。当年项目结束的时候，公司就应该雇人写本《这座该死的工厂是什么鬼玩意儿，以及它如何工作》的书。我们现在的工作实际上就是撰写这本书，但只是由考古学家来做。
反向商业间谍
工作开始后，我和一名前同事收到了另一名前同事的联系，现在他在团队中担任某种管理工作。公司能否聘请我们，提供技术咨询，以便解答关于旧工厂的问题？我同意了，这听上去很有趣，而且他们给我开出时薪是我当年工资的好几倍。
因此我就到达了这个奇怪的工作岗位，试图向公司讲解这工厂的原理。
在这项工作上，我可以利用我个人的几种记忆。我记得一些东西的工作原理，而这些有 30 年历史的工程惯例正是我本人所遵从的。更重要的是，我可以凭印象得知哪些东西是重点，以及这些东西是如何组成一个整体的。
或许同样重要的是，我有一些非正式的文档。在办公室搬迁重组时，文档变得十分紧俏。我需要先顺着线索搜寻到位于已合并多次的文档库中的档案（有一些还卡在进行了一半的数字化工作途中），然后再等好几天才能让他们把文件邮寄给我。偏执的公司管理层制定了关于商业机密的一系列规定，这意味着与聚合物工艺的一切文件都被归类为商业机密。走访承包商办公室时，工作变得难以进行。
于是我们就采用了一种睁只眼、闭只眼的对策，自私复印文件，随身带着走。略加以偏概全的说，工程师都憎恨无理等待，有文件就意味着我们能开工。这也能改善我们给领导的表面印象，因为我们能按时完成任务，而不是回复“在等传真”这种很敷衍的理由。
我现在的工作，是将这些档案走私回公司内。如果可行，我很乐意光明正大的向公司上交这些文件。但这与公司制度完全对不上：在制度上，公司有这些文件（而且使用了数字化管理！），而我没有。但实际上的情况完全相反。但这种事谁愿意去听呢？天知道用什么官方流程能解决这个问题。
因为行不通，文档必须以制度以外的方式被送回它们本应该所处的位置。我们复印了许多副本，并将他们添入了当地团队的图书馆。它们最终大概会以某种方式回到数字文档管理系统——等下一次人们整理东西时发现这些没有编号的文件时，就知道了。我希望这次他们别再把这些东西弄丢了，因为 30 年以后我本人已经不在世了，也不可能再将它们走私回去。
此外，作为公司的外部顾问，文档中涉及的一些商业机密是我不允许接触的。敏感信息需要先经手公司内部的团队，保证信息跨越边界时不被泄漏。遗憾的是，内部团队并不知道商业机密有哪些，而我知道。有几个甚至是我发明的，相关的专利上有我的名字。尽管如此，我还是需要把这些机密走私回公司，让内部团队可以处理这些信息，而内部团队只需保证不再将内容复读给我即可。
我们听说过很多电影一样的商业间谍，但我更希望能看到反向商业间谍的研究。在这种情况中，公司忘记了自己的机密，需要使用非正式手段把它们送回公司内。我确信这种情况比你想象中更常发生。
可解决的问题？
我不确定这个故事究竟告诉了我们什么道理。
更好的组织与档案管理能解决部分问题。但是另一些问题恰恰是试图改善档案管理本身所造成的，所以人们要小心。假如那些实体办公室与档案库还存在的话，也许我们的情况会更好。我们之所以能找到一些档案，就是因为有一个幸存了下来。
传承各项技术与它们重要性的高低的知识，则是更困难的。如果公司员工的年龄段能形成并保持一个连续的坡度，大概会有帮助。这样在老员工退休后，人们就不会坠落于记忆悬崖。
但也许工程考古学会永远存在下去。我越观察（特别是不把目光局限在几年的范围时）就越发觉到，工程世界就像纽约市的地下。一大堆奇怪的工程奇观在人们的视线外默默哼鸣着，他们的设计者是早已被遗忘的古人，留下的只有残破的地图与原理图。
——一名工程师，2011-12-04
译者注：这篇文章发表后，其中所提到的现象发生在了它自己身上。原文出处在几年后就成了死链接，目前网络上现存的版本均为转载。

@wumingshi
果然不是我一个人觉得 tool_call 太别扭
虽然我没怎么理解这里面的逻辑

karminski-牙医
@karminski3
大模型 Tool Call 描述太占上下文的问题解决了?

Manus的后端负责人刚在reddit上发的一篇帖子爆火, 我看完了赶紧给大家整理下他做了什么.

大家都知道大模型配置了 tool call 就可以使用本地工具了, 而且可以跟操作系统交互, 访问本地资源从而完成更复杂的任务. 比如你就可以把视频素材上传到部署了openclaw的电脑, 然后让它剪视频.

但是想要用工具就要把所有的工具都是干什么的写入到 system prompt 中. 一旦工具很多, 就会造成 prompt 失焦, 大模型会忙于选择工具而不是真正的解决问题.

于是这个作者提出了一个全新方法, 不是给AI一堆散的工具, 而是只给一个 run(command="...") 这样的调用模式. 文件操作也好, memory 也好, browser 也好, clip 调用也好, 最后都变成统一命令空间里的 command.

而且这个调用可以利用UNIX管道命令符实现复杂的调用, 最终就会变为 run(command="cat 脚本.md | grep "分镜A" | find ./分镜A.* | ffmpeg ....") 这样来剪辑视频

这样模型不再是在很多 API 之间跳来跳去, 而是在一个自己本来就很熟的 CLI 语境里, 直接表达“我要完成什么流程”.

为什么这么做效果会好呢?

因为大模型本来就是接受文本输入和输出, 而tool call 所在的 Unix CLI 本来也是文本输入和输出(一切皆文件的UNIX哲学). 而 shell 命令则是在所有大模型训练中先天已经训练好的. 所以对大模型来说, 命令行比一大坨 JSON schema 更自然.

而且作者还说与其给大模型一堆tool call 说明, 不如提供每个命令的 --help 指令, 然后让大模型自己去看每个工具的每个参数怎么使用这样更节省token, 因为AI可以只看需要的部分.

所以看懂了吗? 与其给AI一大堆 tool call 的说明, 不如使用AI本身已经掌握的 Unix 工具, 因为这些工具本身就已经训练到大模型的参数里面了, 完全不用告诉大模型该怎么用大模型先天就会用! (魔法往往就这么简单...)

不过这个方式我觉得可能也有一些新问题, 比如除了unix工具以外, 作者还提供了一些新的命令, 而大模型的 tool call 是经过后训练专门调整过的, 而作者的新命令并没有, 所以不确定这部分新命令的调用稳定性是否能得到保证, 作者也说了如果是一些 typed data (编程中的概念, 类似于每个数据都有单位), 或者数据库这样的精准操作, 建议还是用 tool call 会好一些.

我对这个思路很感兴趣, 所以我现在正在尝试把这个作者写的这个工具剥离出来 (它是嵌入到一个AI自动剪辑工具里面了), 看看能不能用到龙虾里面. 如果我测试完效果不错我会放出来个 skill 给大家.

原贴也分享给大家, 推荐一读: http://reddit.com/r/LocalLLaMA/comments/1rrisqn/i_was_backend_lead_at_manus_after_building_agents/