文章摘要
文章认为LLM智能体是一个重要概念，建议读者亲自尝试编写一个，因为只有实践才能真正理解其运作原理，而且实现起来并不困难。无论支持还是反对这一技术，动手实践都是形成正确认知的最佳方式。
文章总结
人人都该尝试编写AI代理程序
作者托马斯·普塔塞克（Thomas Ptacek）在Fly.io博客发表观点：理解某些概念需要亲身体验，就像学习骑自行车一样。在计算机领域，大型语言模型（LLM）代理正是这样的存在——无论你对其持怀疑态度还是热衷追捧，亲自编写一个代理程序都是理解这项技术的最佳方式。
令人惊讶的简易性
作者分享了自己职业生涯中最意外的编程体验：构建AI代理的简易程度令人震惊。仅用15行Python代码就能实现一个基础代理，通过OpenAI Responses API模拟ChatGPT功能。核心代码展示了： 1. 上下文窗口本质上是字符串列表 2. 通过简单修改就能创建多重人格代理 3. 对话记忆通过维护交互历史实现
工具扩展的魔力
文章演示了如何为代理添加"ping"工具功能： 1. 定义工具描述（繁琐的JSON格式） 2. 实现工具调用函数 3. 添加工具处理循环 令人惊叹的是，代理能自主决定何时调用工具，并智能地选择多个Google服务进行网络测试，开发者无需编写具体决策逻辑。
现实世界应用思考
虽然示例简单，但作者指出其核心架构已具备实用价值： - 可扩展更多工具（如traceroute） - 上下文可存入SQLite - 支持多种编程语言实现 特别强调：专业编码代理（如Claude Code）的核心技术完全在个人开发者能力范围内，不必依赖商业解决方案。
上下文工程的实质
作者提出重要观点： 1. "提示工程"可能被过度神话 2. "上下文工程"才是真正的技术挑战 3. 令牌限制迫使开发者创新解决方案（如子代理系统、动态摘要等） 这些本质上都是编程问题，而非魔法咒语。
未知领域的机遇
文章最后指出，AI代理设计涉及多个开放性工程问题： - 不确定性调控 - 事实基础建立 - 多阶段协作机制 - 成本控制策略 这些领域尚无定论，个人开发者完全可能做出突破性贡献。作者鼓励读者亲自动手体验，即使最终选择批判这项技术，也能获得更深刻的认知。
（注：原文中的代码示例、具体技术细节和部分比喻性表述已进行适当简化和本土化转换，保留核心技术观点。）
评论总结
以下是评论内容的总结：
1. 对AI代理开发的看法
支持开发AI代理
- 认为开发AI代理是学习的好方式，尽管可能依赖现有库（如OpenAI），但仍能学到很多（评论7："Write an agent, it's easy! You will learn so much!"）
- 有人分享实际经验，通过开发代理消耗大量资源但收获颇丰（评论21："I did that, burned 2.6B tokens in the process and learned a lot"）
质疑开发AI代理的实用性
- 认为依赖云服务API（如OpenAI）会导致控制权丧失，且技术基础不稳定（评论15："You're building on quicksand... delegating everything important to someone who has no responsibility to you"）
- 建议开发本地代理以更好理解LLM底层原理（评论16："build a local only agent... to better grasp the fundamental nature of what LLM's really are"）
2. 对AI代理技术的讨论
技术复杂性与安全性
- 指出代理开发涉及压缩、安全、沙箱等复杂问题（评论23："Compaction, security, sandboxing, planning... all this is really hard to get right"）
- 警告多代理交互可能引发安全问题，如幻觉或误操作（评论25："a cascade of hallucinations... maybe the system chooses to wipe your home directory"）
MCP技术的争议
- 有人认为MCP只是插件接口，并非核心技术（评论13："MCP is just a plugin interface for Claude Code and Cursor"）
- 反驳称MCP有助于多代理协作和API标准化（评论13："MCP is the only thing out there that's moving in a good direction... enabling us to 'just be programmers'"）
3. 对AI现状的反思
行业混乱与不确定性
- 批评AI领域缺乏共识，项目重复且效果存疑（评论3："so many projects reinvent the same thing... so many hacks with no evidence of them actually working"）
- 比喻LLM为Unix文本工具，强调其可组合性（评论24："LLMs are just UNIX strong manipulation tools... you can compose calls to LLMs"）
开发体验与工程化
- 描述开发个人助理的工程化过程，涉及多代理协作（评论4："the farther you go down this rabbit hole the more 'engineering' it becomes"）
- 强调LLM的“无状态”本质，对话是人为制造的幻觉（评论26："The conversation we’re having is an illusion we cast, on ourselves"）
总结：评论反映了对AI代理开发的热情与担忧，技术路径的分歧（如MCP的作用），以及对行业不确定性的反思。核心争议围绕控制权、安全性和工程化挑战展开。