@zhshch 哈哈 感谢感谢 给了我做出来的动力 希望多提建议

@cheung 哇 这么厉害啊…… 我有个 server.fan 准备英文版用这个。

刚有同学触发了一个 bug，在添加 Agent 的时候，名字和别名都不能重复。发命令的时候用名字和别名都可以的。

但是我忘了翻译这个错误返回提示了，重复了会收到系统错误。

等稍后把 API 文档写完发布出来再修吧。

@fatelight 几乎所有的 IM 都比微信开发起来方便呢 奈何微信有着人手一个不需要额外安装的优势。 后面会有一个版本支持其他的 IM 。

@NewYear 好的后面会考虑 windows 和 Mac 的。

我本来一开始做了 Mac 的，结果发现 MacOS 最新的版本里，连命令行程序都要用花钱的开发者账号签名。 我没有苹果开发者账号诶。Windows 做一个自启动服务应该挺简单的，确实可以用来看是否开机，然后关机，哈哈。

@wpyfawkes 是的 征集蒂蒂+gopher 的图～ 将来有钱了找人去画一个

@MrWhite 哈哈 开发测试不要认证的呢

而且这个是每年 300 还不是一次 300……吃灰一阵子就过期了 不像树莓派可以一直吃

想要和小程序联动，还要注册开放平台，那个是一次性 300.

@NewYear 理论支持的

但是说实话还没想好在 windows 能干什么，我也没试过用 golang 能不能唤起 GUI 应用，所以在 release 里就没发布 windows 的。

其实只是几个 HTTP API 文档这两天很快就出来了…… 完了看着 api 自己随便用什么语言都能调用的。

@xia0chun 好吧 冤枉他们了。是我的锅。我竟然粗心的把 golang 本地化字符串格式写错了……

@xia0chun 哇，你好细心。 真是很诡异呢。 我怀疑 github 的 ci 服务器表不对？ 或者就是 hugo 的问题了。coding.net 的问题可能性更大。 我去看看有没有构建日志。

@lswlray 这是个人项目 木有团队 当然我确实是西安的……

@emmettwoo 谢谢 我会努力的……毕竟传说中程序员都不擅长写文档

还有很多文档没写 这几天一直在抽空写文档

@Sunyanzi 应该是你测试的原因，我这报了不少错哈哈。我还真没硬尝试过微信文档中声明的限制，可如果一直发一样的消息又有什么意义呢？

其实我本来准备做个计数，优先使用客服消息发，没有额度了再用模版消息的。但是因为格式不统一不好表达没做。

下午我再加个利用客服消息回复的接口吧。

@Sunyanzi 持续发消息这个我理解你的意思了。

微信限制收到一句话最多回复 5 条。现在及时反馈 /取走 /结果 用了三条。 其实只剩两条额度了。 我可以考虑怎么节约一下，然后再允许发两条中间状态。

@ashuai 哈哈 低级失误

@wyf001912hp 这个暂时不准备，后面会出一个用 企业微信 /dingding/飞书 /slack/team 任选的，那时候才支持共享之类的。 这个只准备给个人用～

@Sunyanzi 谢谢反馈这么多。已完成的肯定不能更改的，这个会很快修复的。

proceed 的状态在服务端看来就是取走的状态。耗时我来统计一下吧，会显示在成功失败的反馈中。

plan 的文本确实错了～

查询的 rate limit 因为是有 api 的怕有人自己写 Agent 的时候疯狂调用。 准备给普通版一分钟高级版做到三秒之类的。 但是我发现我会的 rate limit 是用 redis 实现的，而取 job 也只是一个 redis 操作，这时候 rate limit 消耗的资源不不 limit 还大…… 但是放在 web server 那一层又会误伤，所以还没想好。

离线是否接受任务我再想想，这个只是设定问题。 有的任务也许发起的人就想现在执行，过一阵等在线了取走执行也许会出事。感觉还是不接受比较好。

@Sunyanzi 可以 fail 多次是个 bug，谢谢。

历史 job 本来想提供 log 功能供回顾一下最近的。不过可以考虑默认删了，用户需要打开 log 再保留。

info 和 warning 的模版不一样，默认颜色也不一样～ 一个是蓝色的一个是红色的

@tcfenix 现在.idea 就是需要同步的呀，里边是项目级别的配置，不需要同步的个别文件有忽略列表的。