从混乱提示到技能工程 | AI生成和翻译
问：如果我们在 Hermes 中设定代理的代码/技能，先编写脚本是否比反复提示代理更好？
答：
是的。这实际上是从 “使用代理” → “工程化代理” 的关键转变之一。
对于像你的 ww 代理框架这样的项目，更好的循环是：
人类意图
↓
编写确定性工作流/脚本
↓
多次运行
↓
观察失败
↓
改进工具 / 技能 / 提示 / 评估
↓
代理变得更好
而不是：
每个任务
↓
新提示
↓
代理猜测
↓
希望它能工作
第二种方法有一个隐藏问题：你无法积累学习成果。
例子：
今天：
“Agent，部署我的服务”
代理使用：
- ssh
- docker
- kubectl
- cloud API
明天：
“Agent，部署我的服务”
可能会走不同的推理路径。
你很难知道：
- 哪一步失败了
- 哪个工具调用有问题
- 哪个假设是错误的
- 哪个上下文缺失了
但如果你将其转化为：
ww deploy production
搭配类似这样的代码：
def deploy():
check_git_status()
run_tests()
build_image()
push_registry()
rollout_k8s()
verify_health()
那么每一次失败都会变成数据。
你可以改进：
1. 技能变成版本化的代码
不再是：
skill:
“知道如何部署”
而是：
skills/
deploy/
README.md
deploy.py
tests/
examples/
现在你可以比较差异：
git diff skill/deploy
并理解改进。
2. 提示变得更小
不好的写法：
你是一位资深 DevOps 工程师。
请部署我的应用...
记住所有这些规则...
好的写法：
使用技能: deploy.production.v3
输入:
app=my-service
env=prod
智能从提示转移到系统。
3. 代理变成规划者，而非执行者
理想的架构：
用户
|
v
LLM 规划器
|
|
决定工作流
|
v
Hermes 技能
|
-----------------
| | |
部署 测试 监控
LLM 擅长：
- 理解意图
- 选择工具
- 适应
代码擅长：
- 可重复性
- 安全性
- 正确性
这与软件工程的演进类似：
之前：
复制/粘贴代码
然后：
函数
然后：
库
然后：
框架
代理目前正在从：
提示工程
转向：
技能工程
有趣的是：你的 ww 方向更接近未来代理系统可能的工作方式。
获胜的代理可能不是提示最长的那个。
它可能具备：
1000 个可靠的技能
+
好的规划器
+
记忆
+
评估循环
类似于人类：
初级工程师每次都问 ChatGPT。
高级工程师拥有：
- 脚本
- 别名
- 内部库
- 调试习惯
- 心智模型
代理需要同样的转变。
参考资料：
- 你的仓库：
lzwjava/ww（GitHub 元数据已访问）
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋