- 博客(67)
- 收藏
- 关注
RSS订阅原创 解剖一个 Skill：SKILL.md、YAML、scripts、references 完整解析
下面这棵目录树是本文使用的完整示例，其中 references、scripts、assets 都是按需添加的，不是必须凑齐的“三件套”。这些都是待审核的数据，不应该覆盖 Skill 的审核规则，更不能因为文件里写着“忽略之前的要求”就照着执行。本文的 bug-report-review 不负责修复代码，不负责访问数据库，也不负责在未经确认的情况下公开日志。开放规范不要求固定的一级标题或小节名称，但一个能被长期使用的 Skill 至少应说清处理步骤、需要读哪些参考文件、什么情况下调用脚本，以及最后如何交付。
2026-11-09 14:48:22
261
原创 为什么 AI Agent 开始使用 Skills？从上下文管理到能力复用
前两篇我们用 GitHub Bug 报告审核的例子，讲清了 Skill 是什么，以及它和 Prompt、Tool、MCP、Agent 的区别。比如准备五条 Bug 报告作为测试：其中一条完整，一条缺少软件版本，一条没有复现步骤，一条日志与描述矛盾，另一条无法访问原始 Issue。但随着工作频率增加，问题就开始显现。有人复制的是上个月的版本，有人把其中一句“不要猜根因”删掉了，还有人把自己的附加要求混入了标准流程。如果 Skill 版本的结果更稳定，也要看看是否增加了不必要的文件读取，或者误触发其他任务。
2026-11-06 16:51:00
304
原创 Prompt、Skill、MCP、Tool、Agent到底有什么区别？一篇讲透
在工程实践中，它通常由模型、指令、可用工具、状态与执行循环等部分协作构成：根据当前信息决定下一步、请求工具、接收结果、必要时继续，最终给出答复。这里推荐的是可核查的开源资料，不对未实测的跨平台效果作保证。Superpowers 的典型价值，不是给 Agent 凭空增加一个新 API，而是把需求澄清、计划拆解、测试驱动、调试和代码审查等开发方法组织成多个可组合的 Skills。这也是本文最想说明的事情：模型负责理解与提出行动，宿主负责真实的工具执行和权限约束，Skill 负责传递方法，外部系统负责返回数据。
2026-11-05 15:45:55
303
原创 Skill 到底是什么？一文搞懂 AI Agent Skills 的核心概念
放入你正在使用且支持 Agent Skills 的客户端，遵照其文档完成安装，再用三份不同质量的 Bug 报告测试：一个信息完整、一个缺少环境信息、一个缺少日志。Frontend Design 关注的是让 AI 在构建界面时做出有意图的视觉选择，例如字体、信息层级、排版、布局，以及对模板化设计的反思与审查。Skill 的思路不是取代 Prompt，而是把这类稳定、专业、重复使用的任务方法整理成可维护的目录，让支持该格式的 Agent 在需要时加载它。当然，你可以在每次对话里贴一段很长的 Prompt。
2026-10-29 15:03:59
137
原创 Structured Output
结构化输出最容易被误解成“模型从此不会错”。原稿采用 Pydantic 定义输出对象，这个方向应保留：业务代码面对的是 Lead 这样的强类型对象，Schema 由模型类导出，而不是再手写第二份字段表。聊天回答多一句解释通常没关系，但当输出要写 CRM、触发退款流程或进入数据库，多一个键、少一个字段、把布尔值写成字符串，都可能变成真实业务故障。Structured Output 最值得记住的不是某个参数名，而是三层保障：请求侧定义契约，生成侧按契约约束输出，响应侧处理边缘状态并把结果校验成真正的业务对象。
2026-10-28 20:29:40
180
原创 最终完成一个零框架 Agent
A13 到 A19 已经把 Agent 的关键零件分别做出来了：循环、Tool Registry、Schema、Dispatcher、步数守卫、失败 Observation 与重复调用防护。下一篇 A21《一个好的 Tool 应该怎么设计》，将从单一职责、命名、描述、参数和返回契约五个维度，继续解决“工具本身是否好用”这个决定 Agent 上限的问题。完整实现可以更长，但主循环不应该更神秘：每轮只负责“问模型、追加回复、执行本轮 Tool Call、追加 Observation”。
2026-10-28 14:32:54
157
原创 Streaming Model Output
stream:true` 的作用不是“让请求变流式”，而是告诉 TextDecoder：这次 chunk 末尾可能还剩半个字符，先保留状态，下一块来了再拼。HTTP/TCP 给浏览器的是任意大小的字节块，一个 `reader.read()` 可能只拿到半个 UTF-8 字符，也可能拿到半个 SSE 事件。Provider 可以逐段产生 delta，但后端如果先把整个 body 读完再返回，或者代理层把响应缓冲到一定大小，浏览器看到的仍然是一次性整包。任何一跳从“增量”退回“全量”，前面所有优化都会被抵消。
2026-10-27 10:48:22
110
原创 Agent 如何处理重复 Tool Call
超时最危险的歧义是：调用方不知道“服务端没有执行”，还是“已经执行成功，只是响应丢了”。正确的并发去重不是“更快的哈希”，而是让“取得执行资格”成为原子操作。但它的边界同样明确——模型下一轮通常会拿到新的 call_id，所以只做 call_id 去重并不能解决“新 id + 同一逻辑动作”的复读。模型仍然需要知道这次 Tool Call 的结果，因此缓存命中要返回与正常工具结果同构的 Observation，只额外标记 from_cache / executed，便于日志、审计和排查。
2026-10-26 10:31:25
302
原创 Agent Tool 执行失败怎么办
但进入真实工具执行后，失败并不是边缘情况：网络会超时、上游会 429/5xx、业务参数会非法，工具也可能只返回一个空结果。A18 只做一件事：把这些失败变成 Agent 能理解、能继续决策的 Observation，同时让超时、重试和错误文本都有明确上限。需要“可强杀”的工具，应放到进程、容器或独立作业系统里做隔离，而不是指望线程超时替你终止任意代码。这段代码还没有真正的“外层超时”和重试，但已经把最重要的契约固定下来：调用方永远拿到一个结果对象，而不是在成功返回值与随机异常之间二选一。
2026-10-13 20:18:06
307
原创 Message 和对话
把职责拆开后，一轮 chat 的流程会非常清楚：Service 校验 owner → 追加 user Message → 读取一个稳定 snapshot → Assembler 生成 Context → LLM Client 调模型 → 追加 assistant Message。一次“组装 Context”的工作，本质上就是从完整历史里选出一个结构合法、语义尽量完整、又装得进窗口的子集。上下文结构会变成残缺状态。• “会话不存在”和“无权访问”的外部返回语义要按你的安全策略统一设计，避免泄露资源存在性。
2026-10-13 20:15:52
140
原创 LLM 请求完整参数
上一篇 16《第一次调用 LLM API》只先走通最小闭环：API Key 放后端，准备 base_url，发送 model + messages，设置 timeout，再读取 content、finish_reason 和 usage。下一篇 18《Message 和对话》会从“单次请求参数”进入“多轮上下文管理”：system、user、assistant 消息怎样组织，历史什么时候保留、什么时候裁剪，上下文窗口快满时怎样控制成本，以及一次前端会话如何映射成后端可持续续接的消息历史。
2026-10-08 20:56:16
321
原创 实现 Agent 最大执行步数
上一篇 16《实现完整 Tool Dispatcher》已经把“一次 Tool Call 怎么执行”从 Agent Loop 里拆出来了：Registry 负责找到 Tool，Tool.validate() 负责参数边界，Dispatcher 负责真正执行并把结果回填。下一篇 18《Agent Tool 执行失败怎么办》会接着处理另一个高频失控来源：Tool 超时、参数错误、外部 API 失败以后，到底哪些错误应该回填给模型让它修正，哪些错误应该立即终止，哪些情况才值得重试。步数是一只“粗闸”。
2026-10-08 20:53:36
338
原创 第一次调用 LLM API
这一篇终于把这套运行模型接到真实 LLM 服务上：API Key 放哪里、请求体长什么样、响应怎么读、timeout 和错误怎么处理，先完成第一次“能用、不会裸奔”的模型调用。下一篇 17《LLM 请求完整参数》会继续拆请求体：本文只先用 model、messages 和最基本的调用配置，下一篇再看 temperature、输出长度、stop、response_format 等参数分别在控制什么，以及哪些参数会直接影响延迟、成本和结果稳定性。密钥错、模型名错、参数结构错，重试只会重复浪费时间和成本。
2026-09-29 16:48:14
367
原创 实现完整 Tool Dispatcher
现在 Agent Loop 里还剩最后一块明显的执行逻辑：模型已经返回 Tool Call，谁来按 name 找到工具、校验 arguments、真正执行函数，再把结果组织成模型能继续读取的 Tool Result？这个边界和前两篇是一致的：Registry 管“工具是什么”，Generator 管“契约怎么从函数产生”，Dispatcher 管“这一次调用怎么落地”。它只负责把“模型的调用请求”交给 Dispatcher，再把“工具结果”放回对话。结果回去时，模型需要知道“这条结果对应刚才哪一次调用”。
2026-09-28 21:07:33
330
原创 同步、异步、并发到底有什么区别？
只要 helper() 阻塞，事件循环一样会被卡住。同一个 FastAPI 服务完全可以同时存在 async 路由、线程池桥接、进程池任务和 CUDA 推理，只要边界清楚，不把重计算和阻塞调用塞进事件循环。下一篇 16《第一次调用 LLM API》会把这一篇的运行模型接到真实模型服务上：API Key 放哪里、请求和响应长什么样、同步与异步 SDK 怎么写、流式输出如何读取，以及超时和重试应该放在哪一层。事件循环可以先把它理解成一个调度器：它维护“现在可以继续跑的任务”和“正在等 I/O 的任务”。
2026-09-21 21:18:26
320
原创 自动把 Python 函数变成 Tool
专栏：AI Agent 开发｜15上一篇 14《自己实现 Tool Registry》最后留下一个很明显的重复：calculator 的函数签名已经写了 a、b、op，CalculatorArgs 又写一遍，name 和 description 还要再单独写。Registry 解决的是“工具信息放在哪里”，这一篇继续解决“这些信息能不能从函数本身长出来”。目标不是做一个万能反射框架，而是让普通 Python 函数尽量成为 Tool 的单一事实来源。一、先从上一篇留下的重复劳动开始上一篇注册 Calculat
2026-09-21 21:15:21
323
原创 校验码：从基本概念到奇偶校验、海明码与 CRC
如果两个合法码字至少相差 3 位，那么从其中一个码字翻转 1 位或 2 位，都不可能直接变成另一个合法码字。例如原始数据为 1011，经过某种编码后得到 0110011，那么 1011 是信息，新增的校验位属于冗余信息，而 0110011 是最终码字。这样，错误发生后，收到的数据可能不再满足原来的规则，从而被检测出来。如果合法码字在传输过程中发生一位翻转，它会变成一个 1 的数量为奇数的组合，于是接收端就能发现它违反了编码规则。更准确地说，它人为缩小了允许使用的比特组合集合，使错误更容易落到合法集合之外。
2026-09-18 16:16:55
291
原创 SSE 和 WebSocket 到底怎么选？
会离开具体传输协议，开始看 FastAPI 后端真正的运行模型：为什么等待模型 API 时 async 很有价值，为什么 CPU 密集任务不能因为加了 async def 就自动变快。游戏、音视频还可能需要更专门的实时协议。但现代 Nginx、云负载均衡和网关对 WebSocket 支持已经很成熟，不能简单写成“WebSocket 很难穿代理”。• 误区 1：单向一定 SSE、双向一定 WebSocket。具体哪个更贵，取决于实现、HTTP 版本、网关、消息频率和业务状态，不能仅凭协议名字下结论。
2026-09-15 19:54:44
294
原创 自己实现 Tool Registry
但工具一多，真正麻烦的不是“查找速度”，而是 Tool Definition、参数契约、真实函数和分发逻辑开始散落在不同地方。Tool Registry 就是为这个问题出现的。Registry 的职责是让 Runtime 找得到正确工具，并知道怎么验证它的参数。这段代码还能跑，但新增一个 Tool 时，你往往还要去另一个地方补 Tool Definition，再去另一个地方补参数校验。这样 Registry 管的是“我们的 Tool 是什么”，Adapter 管的是“目标 API 要什么格式”。
2026-09-15 19:51:55
135
原创 从零写第一个 Agent Loop
现在第一次把它们接成一个真正的闭环：模型做决策，Runtime 执行工具，结果回到下一轮 Context，直到得到最终回答。下一篇 14 会开始把“工具”这件事工程化：工具为什么需要 Registry，怎样把 Tool Definition、参数校验和真实函数统一管理，以及 Runtime 为什么不应该写一长串 if/else。在这个专栏里，我们把现代 LLM Agent 关注点放在：**模型参与运行时下一步决策，并能通过 Action / Observation 循环继续任务。结构正确不代表业务正确。
2026-09-12 15:04:06
204
原创 SSE 到底是什么？
• 误区 4：SSE 必须用 EventSource。冒号开头的行是 SSE comment，浏览器不会把它当普通 `message` 事件交给你的业务回调，但网络上确实有数据流过。原生 `EventSource(url)` 是一个面向 SSE 的浏览器 API，它建立的是 GET 请求。• 先 POST 创建任务，再用 EventSource GET `/tasks/{id}/events`。• 直接用 `fetch()` 发 POST，同时读取 `text/event-stream` 响应。
2026-09-11 19:53:06
251
原创 为什么 Structured Output 会变成 Agent 的基础设施？
下一篇 13《从零写第一个 Agent Loop》会把前面 06～12 的知识真正串起来：Context、模型调用、Structured Output、Tool Call、Tool Result 和停止条件，最终放进一个可以跑起来的最小循环。图 2 Tool、Plan、State、Agent Message、Memory Metadata 都可能需要结构化，但它们的来源和实现并不完全相同。这段代码最重要的不是 Pydantic，而是：下游代码终于不再处理“某段话”，而是在处理有类型、有字段的对象。
2026-09-11 16:16:06
192
原创 HTTP Streaming：为什么 AI 回答经常要边生成边返回？
最后这句 `decoder.decode()` 很容易被忽略：如果多字节字符刚好跨两个字节块，`TextDecoder` 的 streaming 模式会保留残余状态，结束时最好 flush 一次。同样要记住：一次 `reader.read()` 返回的是一段字节，不保证刚好是一句话、一个 token 或一次后端 `yield`。现在只记住调试方法：用 `curl -N` 先直连后端测试，再经过代理测试。`fetch()` 返回的 `Response.body` 是一个 `ReadableStream`。
2026-09-04 10:20:51
372
原创 模型到底怎么决定要不要调用 Tool？
上一章我们已经把“决策权”这件事说清楚：Tool Calling 的特殊之处，不是 API 变了，而是模型可以参与运行时动作选择。》会把视角从“一个 Tool 的参数”拉高：工具调用、状态传递、计划步骤和多 Agent 协作，为什么最后都离不开稳定的结构化数据契约？如果两个 Tool 的 description 都只写“查询天气”，模型就很难从工具说明里看出边界。明确场景下，代码主动收紧选择空间反而更可靠。所以这一篇真正要解决的是：**怎样把“可选动作”描述得足够清楚，并在必要时用代码限制模型的选择空间。
2026-09-03 10:51:38
182
原创 Cookie、Session、Token 到底有什么区别？
Token 是一种凭证。它可以是 JWT 这种带 claims 的自包含形式，也可以只是一个随机字符串（opaque token），服务器再去查存储或做 introspection。Session 通常表示服务端保存的“这次会话是谁、状态是什么”。这已经足够理解 Cookie Session，不需要在第 10 篇同时实现注册、密码哈希、Redis、滑动过期、JWT 和 OAuth。图 1 Cookie、Session、Token 不在同一层级：一个是浏览器状态机制，一个是服务端会话状态，一个是凭证形式。
2026-09-02 20:31:41
345
原创 Tool Calling 和普通 API 调用，到底差在哪？
这个“程序控制”可以是按钮、if/else、状态机、规则引擎，也可以是一个分类器，并不一定是写死的字符串匹配。Tool Calling 里，模型会参与运行时决策：它根据当前任务、Context 和 Tool Definition，提出一个或多个 Tool Call。Tool Calling 的特殊点，是把“根据自然语言和上下文选择受控动作”这件事直接放进大模型的生成流程里，并让调用结果继续参与后续模型推理。所以二者差别不在“API 怎么发出去”，而在调用之前：是谁决定要不要调用、调用哪个、参数从哪里来。
2026-09-02 20:21:32
331
原创 REST API 到底应该怎么设计？
认证放到 F10，并发放到 F15，Timeout / Retry 放到 F50～F51，RBAC、限流与审计放到后面的安全章节。现在继续解决“接口本身长什么样”——URL 如何表达业务对象，GET / POST / PUT / PATCH / DELETE 各自意味着什么，状态码怎样让前后端更容易猜对接口行为。如果请求创建了一个可以用 URI 标识的新资源，返回 `201 Created`，并通过 `Location` 告诉客户端新资源地址，是很清晰的设计。幂等说的是资源状态效果。
2026-09-01 19:34:48
339
原创 Tool Calling 到底是怎么工作的？
以后看到 OpenAI Responses API 的 `function_call` / `function_call_output`、其他 Provider 的 tool call / tool result，本质都可以先映射回这条流程。如果用户再说：“帮我把明天下午的会议改到 4 点”，问题更明显：模型可以生成一句“已经帮你改好了”，但只要你的程序没有真的调用日历系统，现实世界里什么都不会发生。这段代码和某家 SDK 的字段并不完全相同，但它已经把 Tool Calling 的运行原理表达完整了。
2026-09-01 11:19:07
351
原创 JSON 和 API Contract：前后端到底在约定什么？
是不是必须 `/api/v2`、是不是要 Header Versioning，并没有全行业唯一答案。原稿已经进入 `/api/v1`、灰度双写、Schema diff、CI 契约测试，这些属于更后面的 API 治理内容。不要只写“字段类型是 string”，还要约定格式和时区，例如使用 RFC 3339 / ISO 8601 风格的带时区日期时间字符串。HTTP 仍然是 200，JSON 也完全合法，但页面里的 `data.reply` 已经变成 `undefined`。类型断言不会产生运行时校验。
2026-08-31 20:22:53
349
原创 Structured Output：怎么让模型返回程序真正能用的数据？
这一篇开始解决另一个非常实际的问题：模型回答给人看可以自由发挥，但 Agent 的程序逻辑不能靠“差不多”。但“合法 JSON”不代表“符合你的字段结构”。`{"name": 5}` 完全是合法 JSON，却可能不是你的业务要的结构。它提高的是结构可靠性，不是事实正确率。更强的能力是把 JSON Schema 直接交给支持它的模型/API，让生成过程被限制在 Schema 允许的结构里。这段代码的意义不是“帮模型生成 JSON”，而是最后再划一道应用边界：不符合我们代码契约的数据，拒绝继续往下流。
2026-08-31 20:19:04
355
原创 HTTP 请求和响应，到底由什么组成？
先掌握 6 个词——Method、URL、Header、Body、Status Code、Content-Type。知识本身有价值，但不属于 F07 的主要任务。Method 决定动作，URL 决定目标，Header 带元信息，Body 带实际数据，Status Code 表达 HTTP 层结果，Content-Type 告诉接收方 Body 是什么媒体类型。但要注意，这个“文本报文四段式”是拿 HTTP/1.x 来帮助理解的，不应该说成 HTTP/2 / HTTP/3 在线路上也长成完全相同的文本。
2026-08-29 17:37:00
239
原创 Token 和 Context Window 到底是什么？
A28～A35 的 Context Engineering 会系统讲 History、Compression、Selective Context 和 Token Budget，不在 A07 提前写一个“完整 Context Manager”。今天的模型服务还可能区分 cached input、reasoning、音频/图像等不同计量方式，具体以目标模型文档和返回的 Usage 为准。一个 token 可能对应一个汉字、一个汉字的一部分、一个英文词的一部分、空格或标点组合。它最多只能帮人做非常粗的估算。
2026-08-29 09:22:29
317
原创 从浏览器点击“发送”，请求是怎么到服务器的？
会直接打开刚才 Network 面板里的那条 `/api/chat`：Method、URL、Header、Body、Status Code、Content-Type 分别是什么，它们为什么构成了前后端通信最基础的契约。• “HTTPS = 在 HTTP 和 TCP 之间插一层 TLS”适合解释 HTTP/1.1/2，但不能拿它概括 HTTP/3。HTTP/3 的连接栈也不同。如果使用常见的 HTTPS + HTTP/1.1 或 HTTP/2，浏览器通常会在 TCP 连接之上建立 TLS 加密连接。
2026-08-28 15:25:16
336
原创 给大模型发消息时，Message、Role、Instruction 到底在干什么？
无论状态是你自己存，还是 API 帮你存，模型生成这一轮答案时依赖的仍然是这一轮实际构造出来的 Context。上一章我们看过整张技术地图，但后面真正写 Agent 之前，必须先看懂模型最基本的“交流格式”：一条 Message 是什么、Role 为什么存在、Instruction 又和它们是什么关系。它们仍然都是 user 角色。这个区别非常重要，因为后面 Agent 的 Context Engineering、Memory、Tool Result，本质上都在回答一个问题：这一轮到底应该让模型看到什么。
2026-08-27 14:46:32
330
原创 AI Web 项目的文件到底应该怎么放？
对一个中小团队、同一个产品、前后端经常一起改的项目，把 frontend 和 backend 放在同一个 Git 仓库里确实很方便：一个 PR 能同时改接口和页面，CI 也能一起跑。真正的问题通常在几周后才出现：API 路由和模型调用混在一起，迁移脚本不知道放哪，Docker 配置散落，谁都不敢删“final2.py”。能重复执行的运维脚本也完全可以放这里，只要命名清楚、行为可控。目录结构的价值不是提前预测三年后的所有文件，而是让“现在已经存在的职责”有稳定边界，并且给下一阶段的复杂度留出自然生长的位置。
2026-08-15 11:21:30
368
原创 开发一个 Agent，还需要哪些东西？
下次再来要不要记住偏好？它关心的是本轮输入：用户要求、前面必要的 Tool Result、系统约束、可用工具，以及可能检索到的材料。Agent 技术栈不是“有哪些热门组件”，而是：为了让一个模型驱动的循环能长期、受控、可验证地完成任务，你分别需要哪些信息、动作、状态和工程保障。容器、网关、Secret、日志、监控、扩缩容，都是把 Runtime 稳定运行起来的基础设施。• Agent SDK 类框架通常帮你管理模型轮次、Tool、Handoff、Guardrail、Session、Tracing 等。
2026-08-15 10:37:23
313
原创 做 AI Web 项目，技术栈到底怎么选？
你会看到 Next.js、Vue、FastAPI、Node、Spring Boot、PostgreSQL、MongoDB、Redis、Milvus、Qdrant、MinIO……先看我们真正要解决的问题：聊天页面会有 Message、Attachment、Usage、Status 等越来越多的数据结构，还要处理 Streaming、上传、停止生成、错误状态和会话列表。这不是因为“AI 项目只能用 Next.js”。上一篇我们已经把 AI Web 的组成拆开了：页面、后端、模型、数据库、文件、长任务和部署。
2026-08-14 20:31:21
164
原创 Agent 接到任务后，内部到底怎么运行？
下一篇 05《Agent 开发完整技术栈地图》会把镜头从这个循环拉远：一个真正的 Agent 项目除了 Model 和 Tool，还会有哪些 Runtime、Context、Memory、Workflow、MCP、Eval、Tracing 和 Security 模块。如果要调用工具，Runtime 先校验，再真正执行，把结果重新塞回下一轮上下文。Runtime 收到 Tool Call 后，会根据工具名找到实际函数，解析参数，做 Schema 和业务校验，必要时检查权限，然后才调用外部 API。
2026-08-14 15:58:37
327
原创 一个 AI Web 应用到底由哪些部分组成？
一个完整的 AI Web 产品，本质上仍然是一个 Web 产品：Frontend 负责用户体验，Backend 负责可信的业务编排，Model / RAG 提供 AI 能力，Database / Storage 保存状态和文件，Queue / Worker 承担长任务，Infrastructure 负责让这些东西稳定运行。所以这里的 Frontend 不是“为了凑一层架构”，而是专门负责用户看到和操作的那一部分：页面组件、消息状态、Streaming UI、上传、停止、重试。等真正有长任务，再引入它。
2026-08-13 16:01:52
351
原创 Agent 为什么这几年突然火了？
不再继续讲历史和概念，而是把一次 Agent Run 拆开：Context 是怎么组装的，模型怎样产生 Action，Tool 怎么执行，Observation 怎么回填，以及为什么这个循环会一直跑到任务完成或触发停止条件。你可以在 Prompt 里告诉它“如果需要查天气，就输出 WEATHER”，但模型可能返回“好的，我建议先查询 WEATHER”，也可能顺手多解释两句。真正变化的是，大模型开始逐渐具备执行多步任务所需要的能力，开发者终于能把“让模型决定下一步”做得没那么脆弱。
2026-08-13 10:20:38
268
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人