AI和大模型——AI大模型应用的整体框架

一、介绍

在前面对AI大模型的相关具体技术进行了分析和说明，基本上来讲，应该对AI应用有了一个较为清明明白的理解。但是为了能够更好的把握大模型的应用开发，如果能从整体上对大模型的应用整体框架进行说明，即存在一个从单独技术展开再到所有技术综合应用的过程。让大家既能化整为零，又能从零到整，融汇贯通所有技术点，那么对于大模型的应用开发来说，就可以展开下一步的有目的学习，或走向深度加强AI底层技术的技术知识，或走向横向扩展，将大模型应用框架掌握的更广泛。

二、大模型应用的发展

通过前面的文章，对大模型应用的发展已经有了一个很清晰的路线图。大模型的应用，是从简单的提示词到对话框再到上下文管理直到现在的Agent整体交互。在这个过程中，大模型从被简单暴露在用户的面前，到被中间层隔离，再到中间层的不断增加。其实就是将大模型从实验室到普罗大众推广的一个过程。
一系列令普通人眼花缭乱的技术名词不断的出现， Prompt、MCP、Skills、Transformer、RAG等等。用网上的话来说，如果AI圈每几天不暴出几个新名词，那就不是AI圈了。
但是，只要大家回想以前刚刚转到互联时，不也是每段时间就会出现一些新名词或者新的表情么。这个道理是一样的，不用感到奇怪。其实对于AI内部来说，反而更具有典型的技术特征，如果真正的掌握后会发现，它更容易与技术贴合在一起。这对技术从业人员来说，是一种优势。

三、Agent和Harness工程

下面先看一个框图，这样更容易理解AI大模型的主干发展的方向和相关技术名词的关系，理顺了它们，自然也就明白了发展到今天，为什么Agent和Harness成为了当今的焦点。

以上面的图为对照，可以发现，最简单的大模型应用就是从一个简单的提示词到大模型，然后就结束了。然后因为提示词的复杂度提高形成了提示词工程，又因为大模型的上下文处理有限制，所以它们一起又组成了上下文工程。
而随着技术的发展，大模型不但需要提示词，还需要与bash命令进行交互、读写文件以及调用相关工具（如搜索工具），甚至最后可能还需要处理本地的文件写入、查找、查询数据库或第三方接口等等，为了安全需要引入沙箱机制、MCP以及文件管理系统等等。这就形成了一个较为完整的大模型处理系统。
然而，没有人能够保证一次输入的上下文及相关操作可以解决问题，有可能需要反复的进行操作即通过反馈层将上下文进行完善，并且在操作的过程中，可能会产生错误的结果等，这都需要不断的反复的重新增加到上下文工程中即循环处理ReAct。为了防止上下文的腐坏和有效利用上下文空间，就产生了利用规则和约束实现记忆的过程。这里的技术就包括前面提到的RAG等技术点。
一般情况下，达到这种水平，一个较为完整Agent已经可以说完成了。但在实际的应用中，随着向大模型输出的任务越来越复杂，就需要对其进行拆分。目的也很简单，一个是防止上下文溢出，一个是提高处理速度。这个拆分的过程，其实就是任务编排的过程，有点类似于并行编程的任务分配。当再这一层增加到Agent后，Agent基本上就闭环了。
至于最近很火的Harness Engineering则是上图Agent中把大模型去除的所有部分。这样是不是就好理解了。
当然，现在的Agent的应用，已经存在了很多的各种各样的工具和相关的框架服务（如Spec-kit，实现Spec-Driven Development，SDD），不需要大家从头到脚一点点写出来，这点大家要清楚。

四、实际的应用

从目前来看，大模型的应用落地还是相对比较简单的。毕竟几大公司都提供了应用框架的封装。如有名Claude code,Codex等等。
它们一个显著的特点是，基本都已经原生支持了Harness Engineering编程。这样对于开发者落地来说，就已经相对简单很多。更多的是需要开发者自己去理解需求，设计目标和实现及测试路径等。
对应上面的分析其实就是明确需求、拆解任务、制定规则和约束、编写计划、实现步骤、结果验证也就是实现上面的SDD的过程。表现的形式就是对规则线束文件和Skill文件的编写过程。
至于以后这个工作会不会继续被更聪明的AI替代，就不好说了。

五、总结

如果想更好的理解本文，可以与前面的相关技术文章结合在一起，特别是前面的Harness编程部分。这样能够从整体上把握、细节上明白，反复对比，就把AI应用这套框架理解并掌握的明明白白了。