从提示词到生产力

把一段提示词交给模型并得到一段文字输出，离“完成工作”还很远。

当模型需要查询路线、读取文件、运行命令或连接团队系统时，真正发挥作用的不是模型单独的一次回答，而是一套可观察、可约束、可反馈的运行过程。模型理解目标并提出意图；客户端准备上下文、执行受控动作并带回结果；工具把系统连接到真实环境；循环则让任务在反馈中逐步推进。

我将这些日常需要向同事、朋友和家人解释的概念，整理成互动课程站点 Prompt to Product。它不把 LLM 或 Agent 描述成万能能力，而是用动态架构图、执行案例和互动测验，说明大模型技术为何能成为生产力。

术语说明： LLM（Large Language Model，大语言模型）负责理解上下文与生成意图；客户端（Client）是连接用户、模型与工具的运行环境；Agent（智能体）定义角色与工作方式；Skill（技能）沉淀领域知识、工具约束与执行规范；Agentic Loop（智能体循环）由模型决策、客户端执行与结果反馈构成，持续推进任务直至交付。

从回答到行动

为什么大模型只是输出文字，却能使用工具、完成任务？

许多关键问题很难只靠术语定义讲清楚：模型如何“使用”地图、文件或命令行？模型是怎么调用工具的？客户端、Agent 和 Skill 分别做什么？Agentic Loop 又怎样把用户请求推进为可交付的结果？

最终效果往往会掩盖中间过程。课程因此回到工程事实：模型处在什么运行环境中，拿到了哪些上下文，拥有哪些工具权限，又从系统获得了怎样的反馈。只有把这些部分拆开，才能理解能力从何而来、边界又在哪里。

课程一：LLM 应用架构如何演进

第一门课程以可切换的动态拓扑，展示 LLM 应用从单轮问答到多智能体协作的四个阶段。每个阶段都标出参与者、信息流和系统边界。

1. 与单体 LLM 的对话

用户通过客户端向模型发送提示词，客户端再将文本结果返回给用户。模型主要依赖训练时内化的知识，交互通常是单轮、无状态的，也没有接触外部工具。

2. 工具调用

系统增加了工具编排器和外部 API。模型只表达调用工具的意图；客户端或应用负责校验、执行，并将结果回填给模型生成最终回答。

这里最重要的区分是：模型生成的是意图，不是系统动作。文件、网络和命令行的实际操作始终发生在受控的运行环境中。

3. 自主智能体

任务从线性问答变为闭环。模型选择需要的 Skill，客户端读取规范并注入上下文，执行动作、保存状态、回填结果；模型依据新信息继续判断，直到完成目标。

即使系统被称作 Agent，执行权、记忆管理和安全边界仍由客户端持有。

4. 多智能体系统

复杂任务可以按角色拆分：路由器分派任务，研究 Agent 获取资料，执行 Agent 完成工作，审查 Agent 测试并反馈，最后汇总交付。

“多个 Agent”不一定意味着多个模型。它也可以是同一个模型在不同角色提示词、上下文和工具权限下的多次运行。关键是协作关系与交付责任，而不是角色名称的数量。

课程二：为 LLM 配置感官与手脚

第二门课程聚焦 LLM 如何接入真实工具，通过客户端、Agent、Skill 和 Tool Call 的协作边界，拆解一次可执行任务的完整链路。

LLM 是大脑，大模型客户端是运行环境

LLM 擅长理解上下文、生成文本并判断下一步意图，但它本身并不能直接操作文件、命令行或访问网络资源。客户端则负责用户输入输出、上下文组装、历史记录、权限控制与受控工具执行。

可执行的 Agent 产品来自二者协作，而不是把“能做事”归因于模型本身。

Agentic Loop 如何推进任务

标准循环可以概括为：

1. 用户提出目标。
2. 客户端组装上下文并发送给 LLM。
3. 模型判断是否需要工具，并生成调用意图。
4. 客户端在受控环境中执行操作，回填结果、日志和状态。
5. 模型根据反馈继续判断，直至给出交付结果。

用户也可以随时发起新指令，形成包裹在执行循环外的更大交互循环。这个结构使过程可以被展示、审计和中断，而不是一次不可见的“黑箱完成”。

Agent 与 Skill 为什么要解耦

课程将它们分成三类资产：

• Agent 定义岗位、人设与工作方式，回答“谁来做”。
• Skill 沉淀领域知识、工具约束与执行规范，回答“怎样正确做”。
• 客户端 将二者组装为一次可执行请求。

实际运行时，客户端可以先注入 Agent 人设和轻量的 Skill 索引。模型确认需要某项能力后，会生成读取相应 Skill 文档的调用意图；客户端再执行该调用。这样既能提供专业规则，也避免把所有细则一开始就塞进上下文。

Tool Call 的三种常见形态

• Built-in Tools：读取工作区、搜索代码、提出澄清问题等内建能力。
• Shell / Runtime：运行命令、构建项目、执行测试等贴近工程现场的操作。
• MCP / Remote APIs：连接外部平台和服务，将系统的可执行能力延伸到团队系统。

LLM 生成调用意图，不直接取得工具的控制权。因此，沙箱、最小权限、审计记录，以及不可逆操作前的二次确认，应当由客户端或底层系统实施。

生产力来自被编排的注意力

在模型内部，注意力机制帮助 LLM 在上下文中关联不同信息；在工程系统层面，生产力则来自对“注意力”的进一步编排：让合适的目标、上下文、Skill 和工具，在合适的时机进入任务。LLM 的价值不只在于生成更流畅的文字，而在于它能够在这些条件下判断下一步，并通过受控工具参与实际工作。可靠性则不来自对模型“万能”的期待，而来自清晰的职责划分、适当的权限、可回填的反馈，以及对高风险动作的人工确认。

课程站点目前包含上述两门基础课程。下一门课程将讨论模型能力与边界：

• 模型是什么？
• 为什么模型能输出文字？
• 如何理解模型的能力？
• 模型的输出是文字，为何可以调用工具？
• 哪些问题可以直接由模型处理，哪些问题应当借助工具、检索、规则、人工确认或系统约束。

理解模型能做什么，也理解它不能做什么，才能把 LLM 和 Agent 稳妥地用到真正需要的地方。

欢迎访问课程站点：https://llm.hclife.edu.pl/