在AI应用爆发的今天，Agent（智能体）框架正变得越来越庞大、越来越复杂。从最初的上下文管理，到后来的哈尼斯（Harness），再到如今大行其道的Loop工程，整个行业的演进逻辑似乎只有一个方向：追求全自动，让用户交互的次数越来越少。
然而，当我们为了追求极致的自动化而不断堆砌功能时，我们是否正在失去对Agent最核心的掌控？
一、 繁华背后的代价：当Agent变成“不可控的黑盒”
如果你深入使用过主流的Agent框架，一定会被以下三个痛点反复折磨：
- 惊人的Token消耗与“隐形”提示词：为了支撑复杂的自动化流程，框架内部塞入了海量的System Prompt、各类MD配置文件、角色定义等。这些你看不见、摸不着的“隐形提示词”，不仅让Token成本居高不下，更让你永远无法确切知道，大模型到底接收了哪些底层信息。
- 极高的学习成本与部署地狱：各种机制、模式、Skill加载方式层出不穷。一个简单的Agent应用，部署起来却像是一个庞大的微服务系统。你很难搞清楚某个配置究竟会影响什么，更不知道它私底下带了哪些东西。
- 完全失控的“全自动”：大模型调用了哪些工具？传了哪些参数？是否允许执行？当模型自动执行、自动重试时，你就像坐在一个黑盒里，只知道入口和出口，却完全不知道中间它走了哪条路。
二、 回归本质：Agent只是在“自由度”与“可控性”之间拉扯
如果我们拨开层层迷雾，会发现Agent的本质其实极其简单。LLM拥有极高的自由度，但也因此不可控；而传统的IT工程虽然逻辑固定、绝对可控，却缺乏灵活性。Agent，本质上就是在这两者之间来回拉扯的产物。
所谓的上下文管理、RAG、状态保存、断点再续……无论外界包装得多么复杂，理论上来讲，它们最终都只汇聚成一个出口：拼装发给大模型的参数（上下文工程）。无论你是MCP还是Skill，本质上它们都只是一个“工具”。你写个工具，读MCP，最终无非就是调一下工具获得一段文字，然后把文字拼到消息里发给大模型。
基于此，我打造了一款截然不同的Agent框架。它拒绝过度包装，纯Python实现，只做两件事：消息的增删改查，工具的增删改查。
三、 极简实践：透明的消息列表与所见即所得的工具
我的Agent没有复杂的自动化流程，它的核心交互界面只有一个：透明的消息列表。
1. 消息的绝对掌控
你发送给大模型的所有消息，都会以列表形式完全透明地展示在你面前。你觉得顺序不合理？自己调整。觉得中间有干扰信息导致了“Lost in the middle”？直接删掉。你看到的、调整的，就是大模型真正接收到的。
2. 工具的执行权在你手中
当大模型提示需要调用工具时，流程会暂停，将工具名和参数展示在消息列表中。你可以选择原封不动地执行，也可以随时修改参数，甚至直接修改工具返回的结果。确认无误后，再将这些结果拼回消息列表，发给大模型。
四、 终极哲学：先手动跑通，再封装自动；用户知道答案，就不让AI瞎猜
为什么我如此强调手动调整？因为自动化的前提，是你手动完全能跑通。
现在的主流框架是反的：你目标不清晰，不知道如何评判结果，整个流程完全不可控。就算不出问题，模型也要不断尝试、自动重试，这会极大地增加复杂度并消耗海量的Token。
在我的Agent里，你可以从入口一步一步、手动走到最终的结果。无论是写小说还是写代码，哪个环节有问题，你随时能改。当你把整个流程手动跑通、确认无误后，你可以把这套逻辑封装成一个工具。此时，你得到的“全自动”才是真正可控的，因为每一个节点、每一步流程，都是你亲自验证过的。
更重要的是，Agent与用户应当是相辅相成的。如果用户已经知道某些背景信息或关键路径，就应该直接告诉Agent，而不是让Agent自己去摸索和尝试。这不仅节约了大家的时间，更直接节约了昂贵的Token。能直接给答案的时候，绝不让AI去猜。
五、 结语：最少的代码，就是最优的解
在这个越来越复杂的时代，我们选择做减法。Agent的核心价值，应该是让用户能以最简单的流程上手，并对最终的结果拥有明确的控制权。
同样的需求，如果你能用最少的代码实现它，那这最少的代码就是最优的，而不是靠堆砌功能来显得“高级”。如果你只是想写一本小说，你根本不需要那些沉重的自动化框架。你只需要一个能帮你拼装上下文、能让你随时增删改查消息和工具的极简环境。如果有扩展需求，比如想让Agent去小说网站上抓取数据，你只需要自己写一个“网络下载”的工具即可。
真正的强大，不是靠堆砌复杂的自动化流程，而是源于对本质的极致掌控。纯Python、零黑盒、全透明、最少代码——这才是Agent该有的样子。
Easy-Agent一个极简的，可以快速上手的工具，无论你用他写小说，做调研，还是写代码，他就是你最好的脚手架，他是Agent的积木，想要什么功能，完全由你掌控
代码持续完善中：
https://gitee.com/yindeyue/easy-agent
