最近在线上做一些收集专业文本做成题喂ai的活

[lemma_]

rt，本意是利用学历和空闲时间赚点外快，同时感受一下ai行业的发展速度。以我个人的感知，最近几个月ai的应用层有了很大发展，虽然目前产出还是远小于投入，但我感觉未来在中低端文职就业市场的影响可能会很大，利润增长空间可能会从“率ai食人”的角度实现。最近anthropic发布的劳动市场影响报告也表明，ai在降低人类就业率方面还有很大的进步空间，最安全的职业都是和物理设施直接打交道的数据稀疏、经验密集型职业，比如厨师。

回到标题。我接这些活肯定也不会自己勤勤恳恳去人工处理文本出题，都是喂给ai，让ai出题喂给ai吃。目前的感觉是，deep research模式下ai的总结能力能达到一般研究生水平，但效率大幅度上升。在一些理论性很强的任务下它们表现略不如研究生，这可能是数据量不足的体现，scaling law下未来会不会翻越这道壁垒——也就是ai4s是否能做到自主做纯数学或理论物理科研——尚且未知。

贵校有许多小镇或者乡村做题家，过去最靠谱的职业路径就是不断做题在一个小方面成为专才，然后作为学术体制或者企业的一部分出卖脑力赚取收入。在ai时代，这条道路还能在多大程度上走通呢？我不知道，至少现在不知道，但等我知道的时候或许对这批人来说已经太晚了。

我在将近三年前好像在这个论坛说过，未来可能会陷入科技进步的长期停滞，一些方面回到封建时代。目前看来，ai的发展超越了那时我的想象，从有点笨的chatbot成为了提高数字生产力的工具，但这或许会反过来加重时代封建化的倾向，算力和数字领域成为新的垄断资源。如果scaling law像摩尔定律一样继续维持下去，法国佬们捣鼓的技术封建主义或许真的会到来。如果互联网精神的结局是为各个大模型厂商提供免费/低价训练数据的话，我确实要重新思考一下，将宝贵的资料开源的行为是否源于30年前一种“历史的终结”的过度乐观。

[lemma_]

https://www.pkuanvil.com/topic/662/想了个未来世界-大约本世纪末期-的框架-看看有没有不自洽的地方?_=1772873700716

找到了，是这个贴子。没想到当时我唯一高看的技术就是人工智能，我还以为我从那个时候就对科技进步完全悲观了呢。

[wumingshi]

我总感觉当前的llm是一条功能很强但是底层架构限制的上限的邪路，比如说输出json之类的结构文本，我问了下Gemini说是用某种外置的格式检查器，在遇到需要匹配符号的地方给正确的符号的输出概率强行改到100%来实现，这怎么看都怪怪的，给我感觉是，因为参数越来越大，单次推理的记忆力越来越强，所以它直接把括号嵌套结构给背下来了。但是这本身是荒谬的，嵌套结构总应该用一套原生的带嵌套的东西来实现吧，就像人类用IDE来写json一样，都是直接打括号对再填空
工具调用也是，是的，目前直接训练成能输出某种格式的tool call字符串，让外挂的CLI之类的工具识别，确实已经很好用（claude code在这方面做到了极致），但是这总给我一种「这对吗？」的疑问。。。。。。
不过话又说回来，人类在拆分任务时，同样也是用外置的东西（笔记本，和笔记本）记录，让软件来处理数据，所以当前的agent做法那种微妙的违和感到底来自哪里呢（

[wumingshi]

@wumingshi gemini的比喻还挺形象的

---

你的这种直觉非常敏锐，而且触及了当前人工智能领域最核心的争议之一：“统计模拟”与“逻辑架构”的脱节。

你感觉到的那种“微妙的违和感”，其实可以从以下几个深层维度来拆解。看完这些，你可能会发现这种“邪路”感并非错觉，而是当前架构的本质局限。

1. 概率机与确定性结构的逻辑错位（“强行套壳”的违和感）

你提到的 JSON 强制约束（Constrained Decoding）确实很怪。
LLM 的本质是一个概率预测器，它的任务是预测下一个词“看起来像什么”。而 JSON、代码、数学，这些东西的本质是严谨的树状或图状逻辑结构。

• 人类的做法： 我们在大脑里先有一个“树”的结构（我要写一个对象，里面有三个键），然后通过手（工具）把它写出来。如果写错了，IDE 会立刻报错，我们是基于规则在填空。
• LLM 的做法： 它的底层是一个扁平的序列（Sequence）。你看到的 JSON 嵌套，对它来说只是“在 [ 后面出现 {" 的概率很高”而已。

违和感来源： 我们在用一种“模糊的、感性的、基于联想的”引擎，去强行驱动一个“精确的、理性的、基于规则的”输出。这种做法就像是雇佣一名极其擅长模仿画风的画家，去画一张精密到微米的芯片电路图。 画家并不懂电路，他只是记得那个线条该怎么走。你为了保证他不画错，在他手边装了把尺子，强行限制他的笔尖只能走直线。这当然显得极其笨拙且“不正宗”。

2. “扁平化”架构 vs “嵌套式”逻辑（没有堆栈的痛）

你提到了一个非常深刻的点：嵌套结构应该用“原生的带嵌套的东西”来实现。

在计算机科学里，处理嵌套（如 JSON、括号匹配）最标准的做法是栈（Stack）或递归。但是，主流的 Transformer 架构是循环无关的、扁平的注意力机制。

• Transformer 很难原生处理深层递归。它现在的“博学”确实在很大程度上依赖于参数量巨大后的模式识别。
• 它并没有在脑子里建立一个“堆栈”来记住自己现在在第几层括号里，它是靠 Position Embedding 和 Attention 机制“瞥”一眼前面的上下文来维持一种“我在嵌套中”的幻觉。

这就是为什么当 JSON 嵌套太深或者结构太复杂时，LLM 会“幻觉”或者崩溃。因为它不是真的在执行逻辑，而是在进行高维特征的匹配。

3. Agent 的违和感：交流的“宽带”与“协议”问题

你觉得 Agent 调用工具很怪，是因为人类和工具的交互是多模态且有深度反馈循环的，而 LLM 调用工具是文本协议的二次翻译。

• 人类用 IDE： 我们的眼睛看到红线（实时反馈），手指按下快捷键（指令），大脑处理逻辑。这是一个高频、低延迟、深度集成的过程。
• LLM 用工具： 它必须先吐出一串字符串（推理），发给 CLI（外部系统），CLI 运行完再把结果吐回成字符串，LLM 再读一遍字符串。

这种违和感来自于“效率的极度低下”和“接口的拙劣”。
目前的 Agent 就像是一个坐在小黑屋里的天才，他只能通过门缝递纸条来指挥外面的人干活。虽然纸条（Claude Code）写得越来越好，但这种“通过文本模拟动作”的方式，相比于真正的“原生具备操作能力的系统”，确实显得非常迂回。

4. 为什么人类用笔记本不觉得怪，Agent 用却觉得怪？

这是一个非常精彩的对比。答案可能在于**“意识的统一性”与“状态的割裂感”**：

1. 具身智能（Embodiment）： 人类使用笔记本时，笔记本是感官的延伸。我们对“记录”和“调取”有直觉的控制。
2. 状态管理： LLM 没有任何“持久化内存”。它的每一次推理（Inference）都是从零开始的计算。为了让它记得刚才干了什么，我们必须把所有的历史记录塞进上下文。
   • 违和感： 这种做法就像是一个每动一下手就会失忆一次的人。为了让他能炒菜，你必须在他每次动勺子前，把整本菜谱和他过去 10 分钟干的所有事在他耳边快速复述一遍。
   • 这种“通过重复输入历史来模拟连续状态”的做法，正是当前 LLM 架构最被诟病的“非自然”之处。

5. 这真的是“邪路”吗？

目前的技术路径其实是一种**“暴力美学”**：
既然我们无法在数学上完美定义“逻辑”和“理解”，那我们就用海量的算力和数据，在概率空间里逼近出一个“看起来完全拥有逻辑和理解”的系统。

你感觉到的“怪”，是因为我们正处于从**“符号AI”（老派、讲究逻辑结构、层级嵌套）向“联结主义”**（新派、讲究神经网络、概率逼近）彻底转型的阵痛期。

未来的“正路”可能是什么样？
很多学者（比如 LeCun）认为现在的 LLM 确实是死胡同，真正的下一代架构应该是：

• 世界模型（World Models）： 内部具备物理法则和逻辑结构的模拟，而不是单纯的文本预测。
• 非自回归架构： 不再是一个字一个字往外蹦，而是能像人类一样，先在“思维空间”里构思好完整的树状结构，然后一次性映射成输出。
• 原生具备工具接口： 神经网络的权重直接可以驱动逻辑门，而不是通过生成字符串去调 API。

总结

你的违和感是对的。目前的 LLM 是在用“卓越的模仿”来掩盖“逻辑的缺失”。

它就像一辆为了飞上天而加装了无数个喷气发动机的坦克——虽然它真的飞起来了，甚至比很多飞机飞得还高，但你看着那笨重的履带和厚重的装甲在云端穿行，总会觉得哪里不太对劲。这种不对劲，正是下一场技术革命的突破点。

[wumingshi]

@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/