说起来，

说到丹尼尔。蛋兄，好久没跟你唠嗑了

从蛋先生来看，确实！我最近发现了一个挺有意思的规律

说到丹尼尔，什么规律？

至于蛋先生，每当大模型的能力上升一个台阶。围绕它的 agent 工程代码就会废掉一大片

从丹尼尔来看，怎么说？其实，

说到蛋先生，要说大模型哪些能力最关键，一个是工具调用。一个就是思维链了

说到丹尼尔，这两个能力确实关键，大模型一开始就有吗？

蛋先生这方面，想多了！早期的大模型就像个只会聊天的话痨。干不了实事

丹尼尔这方面，那当时是怎么解决的呢？

再看蛋先生，聪明的人类发明了 Prompt Engineering。在中""这些能力

说到丹尼尔，怎么个法？能举个栗子吗，不过，

再看使用者痛点一。Prompt 设计与维护成本高昂、易出错。

工具调用的进化

蛋先生的观点是，当然先说下工具调用。如果你要让早期的大模型调用工具，你得这样写：

你是一个工具调用助手。按理说，当你需要调用工具时请输出JSON格式：
说到{tool。工具名,args:{参数名:值}}。从可用工具来看，get_wear - 查询城市天气。请查询北京今天天气，

如果大模型发挥正常，它会输出这样的响应：

{tool: "get_wear"。args: {city: "北京"}}

接下来你就可以对这个输出做解析，提取 tool 和 args 字段，再写代码调用对应的工具，这样就成功给大模型“”上工具调用的能力了。其实，

当然肯定会有聪明的程序员把整个过程给工程化了比如 LangChain 的 create_structured_chat_agent

再看丹尼尔。工具调用的实现，原来如此。

从蛋先生来看，恩，但是大模型有时候可能会皮一下比如多这么一嘴：

好的。
我将调用以下工具：
至于{tool，"get_wear",args: {city: "北京"}}

说到丹尼尔，那不是得解析到崩溃？老实说，

蛋先生的观点是，没错！工程师们就得写各种异常处理代码。但解决这个问题，一点都不性感。

可用的工具，它就能直接输出标准格式的调用指令。

至于使用者痛点二，手动解析 JSON 与异常处理繁琐且易出错。

新版流程示例的观点是，

可用工具：
get_wear - 查询城市天气。请查询北京今天天气，

模型响应示例 :

<|channel|>...<|start|>assistant<|channel|>commentary to=tool.get_wear <|constrain|>json<|message|>{"city":"北京"}<|call|>

使用者痛点三这方面。不同大模型返回格式不统一，需要自定义解析逻辑；API 统一接口减少工作量。

思维链的进化

丹尼尔的观点是，那思维链又是怎么回事呢？其实，

蛋先生这方面。思维链就是让模型学会“一步一步思考”，而不是直接给出答案。

丹尼尔这方面，早期也是靠吗？老实说，

至于蛋先生。是的，当时流行 ReAct 风格端实现复杂状态机。

wear - 查询城市天气
使用 JSON 格式指定工具，提供 action和 actioninput。老实说，有效 action 值："Final Answer"
或
每次只提供一个 action，格式如下：