AI通识01|程序为何诞生,Agent如何改写并与它共存

AI 通识 · 第 01 课核心问题：人怎样把重复步骤交给机器，Agent 又改变了什么？

先把 AI 放到一边，想象一家每天要处理上千份订单的餐厅。

每来一份订单，员工都要核对菜品、库存、价格、地址和支付状态，再安排出餐与配送。

程序的起点，是把人类反复执行的步骤写成机器可以持续执行的规则。

01｜重复步骤怎样变成程序

人第一次完成任务时，通常会边观察、边判断、边行动。

餐厅员工看到订单后，会先确认菜品是否有货，再计算价格，最后通知后厨出餐。

如果这种任务偶尔发生一次，由人处理就够了。

当同一套步骤每天重复上千次，问题就变成速度、稳定性和成本。

人会疲劳，会漏看信息，也很难保证每个人都按同一套规则处理。

这时，开发者会观察人的做法，找出其中反复出现、能够说清楚的部分。

例如：读取订单、检查库存、计算价格、记录支付、改变订单状态。

接着，人要为每一步写清输入、动作、结果和例外情况。

库存为零怎么办？支付失败怎么办？地址超出配送范围怎么办？

这些规则被代码表达后，机器就能按照同一套逻辑反复执行。

 

02｜代码是一份精确的操作说明

代码听起来很技术，其实可以先把它理解成一份写给计算机的操作说明。

人类写说明时可以说“看看还有没有货，有货就下单”。

人能结合常识理解“货”指什么，也知道数量不够时应该停下来询问。

计算机没有这层生活经验。说明必须写得足够明确：读取哪个数据、比较什么、执行什么动作。

如果 库存数量 ≥ 订单数量  扣减库存，并创建订单否则  返回“库存不足”

这几行还不是某种真实编程语言，但已经有了代码最重要的形状。

它把一句含糊的人话，拆成条件、动作和结果，让每次执行都有清楚依据。

真正的代码会使用 Python、JavaScript 等编程语言，并遵守更严格的词汇和语法。

代码写在文件里时只是一段文本。机器加载并执行它之后，它才会读取数据、改变状态并产生结果。

定义卡｜代码　代码是人用编程语言写下的精确操作说明，告诉计算机按什么顺序做什么。

03｜代码为什么能在电脑里运行

代码为什么能被电脑运行？中间还需要一次“翻译”。

电脑里的处理器，也就是 CPU，能够直接执行的是一组非常基础的机器指令。

这些指令可以读取数据、进行计算、比较大小、跳到另一条指令，或把结果写回内存。

人当然不愿意每天直接编写这些底层指令，所以才有了更接近人类表达的编程语言。

开发者写下 Python、JavaScript 等源代码，再由编译器、解释器或运行时负责转换和执行。

具体工具因语言而不同。C/C++ 常用 GCC 或 Clang 编译，Python 常由 CPython 解释执行。

JavaScript 可以由 V8 运行时处理，在运行过程中完成编译与优化。

有些代码会在运行前被转换，有些会在运行过程中逐步解释或编译，但目的相同。

它们都要把人写的操作说明，变成处理器能够执行的指令。

运行程序时，操作系统会把需要的代码和数据放进内存，并为它提供文件、网络等资源。

CPU 从内存中依次取出指令并执行，结果再被写回内存、文件、屏幕或其他设备。

人写的源代码  ↓编译器 / 解释器 / 运行时  ↓处理器能执行的机器指令  ↓CPU 读取并执行  ↓数据或设备状态发生变化

 

运行卡｜代码为什么能运行　工具把源代码转换成机器指令，操作系统装载资源，CPU负责执行。

04｜代码怎样组成可以工作的程序

现实任务  ↓人完成一次  ↓找出重复步骤  ↓写成规则和代码  ↓机器自动执行

代码可以只有几行，也可以分散在成千上万个文件里。

当这些代码与需要的数据、配置和运行环境组合起来，就形成了可以工作的程序系统。

定义卡｜程序　程序让代码真正运行起来，持续完成已经定义清楚的任务。

这里的自动化不只代表“少点几次按钮”。

计算、校验、记录、传输、控制设备和改变状态，都可以成为程序自动执行的步骤。

程序也不需要一次替代人的全部工作。它通常先接走最稳定、最重复、最容易验收的部分。

05｜控制流让程序按顺序行动

代码要真正运行，还需要规定每一步的先后关系。

订单程序要处理输入、状态、条件和动作。

输入是菜品、数量和地址，状态是库存、支付结果和配送进度。

条件决定是否进入某条分支，动作则计算价格、修改库存或调用支付系统。

程序员会写好主要路径，也会写好缺货、退款和支付失败时应该走哪条分支。

程序并不只有一条直线。分支、循环、函数调用和状态机，都可以改变执行顺序。

定义卡｜控制流　控制流规定系统接下来执行哪一步，以及什么条件会改变路径。

06｜程序怎样改变现实

程序的价值，是把已经想清楚的规则变成稳定、可重复、可测试的执行能力。

同样的输入经过同样的规则，通常会得到可以预期的结果。

银行因此能处理大量交易，工厂能稳定控制生产，平台也能同时服务海量用户。

组织里的经验不再只留在某个人脑中，它可以被写进系统，交给机器持续执行。

程序也会反过来塑造现实：人要提供系统认识的输入，任务要适应系统能够处理的路径。

无法提前列出的情况，往往会变成“系统不支持”，最后重新交回人工处理。

影响卡｜程序改变现实　程序让重复步骤规模化执行，也让现实被整理成输入、规则和流程。

程序把确定的部分做得非常可靠，但它很难直接接住那些需要临场取舍的部分。

07｜算法能处理复杂输入，为什么还要人补位

再回到餐厅。程序已经接走了库存校验、价格计算、收款和订单状态更新。

正常订单可以快速流转，员工不必每次重新计算和记录。

但突然下起暴雨，配送时间从 30 分钟变成 80 分钟。

一位顾客马上要开会，另一位顾客备注了过敏信息，替代菜品又刚好缺货。

这时需要处理的已经不是单独一条规则，而是多个目标和限制之间的取舍。

人会结合上下文判断：哪条约束最重要，应该先查什么，需要向谁确认。

开发者不一定只能继续堆条件，还可以设计算法。

可以先把算法理解成一套为某类问题设计、能够重复使用的求解方法。

定义卡｜算法　算法规定怎样把输入一步步处理成结果。

算法可以先筛掉超出预算的店铺，再按距离、价格和配送时间给候选项评分。

分类算法也可以把投诉分到退款、配送或菜品质量等不同队列。

输入变化时，排序、分类和路线都可能改变，算法仍然能够处理大量不同情况。

但算法要解决什么问题、读取哪些数据、按照什么目标计算，通常已经由人提前确定。

候选店铺  ↓按预算和口味筛选  ↓按距离、价格、时间评分  ↓选择得分最高的结果

它比一长串 if/else 更能处理复杂输入，却仍在执行预先设计好的求解方法。

判断卡｜算法　结果可以随数据变化，但计算目标和求解方法仍可在运行前确定。

固定工作流还能把程序与算法连接起来：接收订单、排序候选、检查库存、收款和配送。

只要主要步骤和转向条件已经写好，它仍然更接近程序或工作流。

难点在于，现实中的例外可以不断组合，开发者很难提前列完所有情况。

规则越堆越多，维护成本越高；没有覆盖的新情况，仍要交给人临场判断。

阶段结论｜程序与算法　它们能处理复杂数据，但仍需要人定义问题、目标和求解边界。

08｜Agent 怎样在运行时形成下一步

先观察人在开放任务里怎样工作。

餐厅经理不会背着一张包含所有例外的流程图，而是先确认目标，再观察现场。

他会选择一个动作，查看结果，然后决定继续、换路、追问还是停止。

Agent 尝试把这套“边做边决定”的过程放进程序运行期间。

Agent 系统本身仍然由程序搭建。变化在于，外层程序会在任务过程中反复调用 AI 模型。

负责让整个系统运转的外层程序，可以称为 Agent 运行程序。

它保存目标和当前状态，把相关信息交给模型，再接收模型返回的下一步建议。

更准确地说，这个循环是这样运行的：

用户提出目标  ↓Agent 运行程序整理目标、状态和可用工具  ↓AI 模型提出下一步或生成工具调用请求  ↓运行程序检查权限与参数，再调用工具  ↓工具背后的业务程序执行，并返回结果  ↓结果进入新一轮判断，或停止并交给人确认

现在，你提出目标：“找一份 35 元以内、不辣、清淡、半小时能送到的午饭。”

Agent 运行程序先把目标、已有信息和可用工具说明一起交给模型。

模型识别预算、口味和时间，再返回“查询店铺”或“向用户追问”等下一步建议。

运行程序检查这项请求是否允许，再通过工具调用店铺查询、优惠计算等业务程序。

工具把查询结果返回，运行程序将结果加入上下文，再次调用模型判断下一步。

循环可能继续搜索、调整条件或向你追问，也可能在找到候选方案后停止。

付款仍然需要确认，程序继续负责权限、交易和订单状态。

定义卡｜本课所说的 Agent　它让模型在程序设定的边界内，依据环境反馈参与形成下一步。

单独一个大语言模型还不是完整 Agent。

模型不能直接查询库存或完成付款，它只能返回文字结果或结构化的工具调用请求。

工具也不是另一个智能角色。它是接口，背后连接查询、计算、写入或控制设备的程序。

Agent 运行程序负责保存状态、调用模型、检查请求、执行工具、记录结果和控制停止。

关系卡｜三层关系　模型提出下一步，运行程序负责调度，工具连接真实的软件能力。

 

这张图仍然只问一个问题：下一步由谁、在什么时候决定？

路径主要在开发阶段写好，它更接近程序或工作流。

模型会依据目标、环境和结果，在运行时提出新的步骤，它就具有更多 Agent 特征。

判断卡｜Agent 特征　模型会生成内容还不够，系统还要能依据结果改变后续行动。

09｜Agent 和传统程序是怎样嵌套的

Agent 带来的变化，首先发生在控制流。

过去，开发者尽量提前写完步骤和分支；现在，部分“下一步”可以在运行时决定。

软件的入口也随之变化：用户可以直接说明目标，不必自己拆出完整操作顺序。

关系卡｜改写　Agent 把一部分控制流从开发阶段移到了运行时。

但 Agent 不是一个脱离程序独立存在的新角色。Agent 运行程序本身就是软件系统。

模型被这个程序调用，工具也由这个程序描述、检查和执行。

工具背后再连接库存、价格、订单、支付等已有业务程序或外部服务。

因此，这些部分不是三个并列角色，而是一套有层级的调用关系。

人：定义目标、授权、确认  ↓Agent 运行程序：保存状态、组织循环、检查权限  ├─ 调用 AI 模型：理解信息，提出下一步  └─ 调用工具接口：连接并执行已有业务程序                    ↓              查询、计算、写入、支付、记录

关系卡｜嵌套　Agent 是程序组织方式；模型参与决策，工具把建议接到可执行程序上。

人仍然负责定义目标、授权能力，并在付款、发送和删除等关键动作前确认。

现实产品也常把两种控制方式放在同一个系统里。

确定部分继续使用程序和工作流，开放部分才交给 Agent 动态判断。

10｜什么时候值得使用 Agent

如果每天点同一家店的同一份套餐，固定程序最稳定，也最便宜。

如果公司每天 12 点订 20 份相同盒饭，定时工作流更合适。

预算、口味和店铺变化，并不自动意味着需要 Agent。

如果筛选条件和评分目标可以提前写清，算法或工作流通常已经足够。

当后续步骤无法提前列完，需要根据每次结果决定查什么、问什么或调用什么时，Agent 才更可能产生价值。

 

灵活性也有代价。Agent 循环每增加一轮，就会增加模型调用、工具调用和等待时间。

前一步理解错了，后续动作还可能沿着错误方向继续，形成复合错误。

当工具能够付款、发送消息或删除文件时，判断错误还会产生真实后果。

所以 Agent 系统仍需要权限边界、停止条件、日志和人工确认。

选择卡｜是否需要 Agent　先问路径能否稳定预写；能写完时，优先使用更简单的方案。

11｜换个场景，检验是否真的理解

公司规定：票价不超过 800 元就订航班，否则改订高铁。系统可以自动执行这条规则。

它会走不同分支，但规则和路径已经写好，所以更接近固定工作流。

换成“避开已有会议，在差旅政策内选择总成本最低的方案”，也不一定需要 Agent。

如果日历、价格、政策和评分公式都明确，优化算法仍然可以计算交通与住宿组合。

再换一种要求：“帮我安排这次出差，冲突就和相关人员协调，信息不足时先问我。”

系统可能要查日历、读取政策、比较方案、发送询问，并根据回复重新规划。

这些步骤无法提前稳定列完，模型需要依据新结果持续提出下一步，Agent 特征才更明显。

迁移卡｜判断方法　数据变化和计算复杂都不等于 Agent；关键是步骤能否提前稳定写完。

学完这一课，看到任何“AI Agent”，至少先问三个问题：

1. 下一步是预先写好的，还是模型根据现场结果提出的？

2. 模型建议由哪个运行程序检查、执行和记录？

3. 高风险动作由谁确认？

回答完这三个问题，你就能判断它主要依靠预设算法和工作流，还是 Agent 运行循环。

但这里还缺一块：Agent 用什么做出这些判断？

它的核心决策能力来自 AI。模型产生结果，Agent 运行程序再依据结果组织后续步骤。

问题也随之出现：模型为什么能给出答案？答案很流畅时，为什么仍可能是错的？

下一课，我们会先解释 AI 是什么，再认识三类常见能力：识别与预测、生成、参与行动决策。

我们还会沿着一条统一链路，看懂 AI 的结果从哪里来：

输入 → 模型处理 → 产生候选结果 → 输出 → 人类甄别

最重要的是建立一个判断：AI 产生的是计算结果，不是自动得到认证的事实。

数据可能不完整，问题可能有歧义，模型也可能缺少现场信息。

因此，AI 的错误并非偶然插曲，而是使用 AI 时必须认识和管理的一部分。

下一课｜AI 如何产生结果，又为什么会犯错　认识 AI 的定义与类型，理解结果产生方式，并学会在使用前甄别。

本课结论｜控制流　Agent 改写软件的关键，是把部分控制流从开发阶段交给运行时。